>2018
>обосрест
Одно слово. GraphQL.
>обосрест
Одно слово. GraphQL.
>мы скрываем от пользователя детали реализации
Как же вы заебали сраные ООПшники, сокрытие деталей реализации, как и сокрытие данных - это не инкапсуляция.
>Ведь REST - это буквально о том, как ресурсу (объекту) пользователь устанавливает напрямую атрибуты.
Ресурс != объект. Реализация ресурса может быть любой. Объект, группа объектов, рекорды в бд, файл, да хуй знает что еще, а может даже адовая смесь этого всего может стать одним ресурсом в REST. Ты занимаешься (как и почти все CRUDOSHLYOPI) натягиванием REST на OOP, что в корне не верно.
Самый правильный способ с точки зрения REST решения данной задачи:
PUT /invitations/:id
time="..."&place="..."
POST /invitations/:id
decision=accepted|refused
Возвращает:
201
Location /invitations_decisions/:id
Повторный POST возвращает 405 или 409 в зависимости от семантики
GET /invitations/:id/decision
Возвращает:
303
Location /invitations_decisions/:id
Дружище, не рвись. Я правда хочу разобраться.
> сокрытие деталей реализации, как и сокрытие данных - это не инкапсуляция.
Интересно узнать почему ты так считаешь.
>POST /invitations/:id
>decision=accepted|refused
Насколько мне известно, REST велит использовать PUT когда адрес ресурса известен, а POST - когда неизвестен. Например, при создании адрес будущего ресурса еще не известен. А здесь известен, и следовательно PUT. Несогласен?
И вообще, почему в первом запросе у тебя PUT, а во втором POST?
>Интересно узнать почему ты так считаешь.
Потому что по определению инкапсуляция - это объединение кода и данных в единый компонент. Про сокрытие ни слова. В REST кода никакого нет, одни данные.
>И вообще, почему в первом запросе у тебя PUT, а во втором POST?
Первый запрос - демонстрация API на изменение свойств приглашения.
Второй запрос - демонстрация создания ресурса "решение" к приглашению. При этом сам ресурс "решение" создается в коллекции
/invitations_decisions, о чем говорит ответ сервера.
Можно, конечно, сделать и так:
POST /invitations_decisions
invitation_id=invitation_id&decision=accepted|refused
Возвращает:
201
Location /invitations_decisions/:id
Но получается это как-то в отрыве от invitation и мне не очень нравится.
Но тут уже погромист должен смотреть какое API лучше описывает предметную область.
>Потому что по определению инкапсуляция - это объединение кода и данных в единый компонент. Про сокрытие ни слова.
Мы вам перезвоним.
Инкапсуляцией называют и то и другое.
А вообще ооп ваше нахуй не нужно.
Маня с сосача только разве что. Инкапсуляция всегда означает сокрытие деталей.
>А вообще ооп ваше нахуй не нужно.
Два пикрила тебе анончик.
Убери ооп и ничего не останется
ООП - с ним как с быдлом: все быдло, кроме меня; православное ООП только у меня, а остальные несут ересь.
Только на сосаче в манямирке вкатывальщиков-борщехлебов.
Нет, голубчик.
Манямирок - это верить, что у маркетингового баззворда, который каждый крутит как хочет чем собственно и является ООП, существует какое-то строгое определение в хоть сколько-нибудь научном смысле.
>Инкапсуляцией называют и то и другое.
Потому что дебилы неграмотные.
Слава богу. Один дебил написал, обезьянки повторили.
>Инкапсуляция всегда означает сокрытие деталей.
Это называется абстракция, маня.
In object oriented programming languages, encapsulation is used to refer to one of two related but distinct notions, and sometimes to the combination[1][2] thereof:
A language mechanism for restricting direct access to some of the object's components.[3][4]
A language construct that facilitates the bundling of data with the methods (or other functions) operating on that data.[5][6]
A language mechanism for restricting direct access to some of the object's components.[3][4]
A language construct that facilitates the bundling of data with the methods (or other functions) operating on that data.[5][6]
>Это называется абстракция, маня.
Че долбаеб?
Хуй тебе в очо.
Даже зарифмовать не можешь. Точно долбаеб.
>>Инкапсуляция всегда означает сокрытие деталей.
>Это называется абстракция, маня.
В двух этих утверждениях нет противоречия маня.
>В двух этих утверждениях нет противоречия
Только для тех, у кого ООП головного мозга, инкапсуляция неотрывна от сокрытия, т.е. от абстракции. У нормальных людей эти понятия ортогональны.
Прекрати троллить тупостью.
Я то раньше думал что абстрактная мамка - это просто женшина у которой есть дети, безотносительно ее цвета глаз, размера сисек и тд. Оказывается, что абстрактная мамка - это беременная женщина, инкапсулировавшая ребенка.
Композиция в действии
Хуемразь плиз, ребёнок это dependency injection.
Именно так и есть. Абстрактная мамка - это женщина с детьми. Остальные детали реализации, как-то цвет глаз, размер влагалища и другие, нам уже не важны, кому нужна разведенка с прицепом?
>беременная женщина, инкапсулировавшая ребенка.
Читай двух анонов выше.
Инкапсуляция - это, например, уровни блядства, феминизма, ламповости и соответствующее им поведение.
>блядства, феминизма, ламповости
При этом мы даже можем менять эти параметры, например, пиздюлями, чтобы добиться требуемого поведения, но это плохо, так как ведет к сильному зацеплению и слабой связанности.
>Инкапсуляция - это, например, уровни блядства, феминизма, ламповости и соответствующее им поведение.
Звучит как Dependency Injection!
Мимо хуеющий с ваших метафор
>Звучит как Dependency Injection!
Ох нет, это все свойства объекта. Имя и возраст мамаши тоже в Dependency Injection запишешь?
Кстати, возраст мамаши, таки, инкапсулирован с мамашей, однако его доступность сильно зависит от конкретной реализации, а так же ФГМ мамаши. Может быть как закрытым для чтения (у дам такое не спрашивают), открытым для чтения (у похуистичных тян), открытым для записи (а сколько дашь?), и даже иногда константным, равным 18.
Ну так какого хуя этот ваш РЕСТ нарушает ООП.
Только в головах ООП-даунов, не понимающих сути РЕСТ.
REST -- стиль организации протокола взаимодействия распределенной системы, вероятно по сети.
ООП -- парадигма программирования конкретного приложения.
Сущности, как легко заметить, несколько разных порядков, и конфликтовать они могут только в голове ОПа.
А ИРЛ взаимодействовать RESTful могут код клиента, написанный процедурной лапшой и колбэками, сервак на ООП, который ещё дёргает хипстерский микросервис, полный монад и функциональщины.
/thread
ООП -- парадигма программирования конкретного приложения.
Сущности, как легко заметить, несколько разных порядков, и конфликтовать они могут только в голове ОПа.
А ИРЛ взаимодействовать RESTful могут код клиента, написанный процедурной лапшой и колбэками, сервак на ООП, который ещё дёргает хипстерский микросервис, полный монад и функциональщины.
/thread
>Ведь REST - это буквально о том, как ресурсу (объекту) пользователь устанавливает напрямую атрибуты.
Долбоеб? Ресурс != объект.
Клиент посылает запрос на апдейт ресурса, получает ответ об успехе или ошибке/редирект/whatever. Всё.
Какие именно объекты скрываются за этим ресурсом, какие у них поля и тд - об этом клиент вообще не знает, как и деталей реализации.
Зачем ты начал связывать ооп с rest это отдельный вопрос.
В теории взаимодействовать может что угодно и как угодно. А ИРЛ 99.9% веб-девов пишут на ОО-языках, и для АПИ используют РЕСТ. И мой вопрос в том, зачем с радостью натягивать сову на глобус, если эти концепции в принципе друг другу не подходят.
> если эти концепции в принципе друг другу не подходят.
Все равно, что спиздануть "public interface ComparableHui { public double size(); } не подходит для ООП". Ну не долбоеб ли ты?
Не понял, к какому именно моему аргументу адресован твой контраргумент?
Не понял, к какому именно моему аргументу адресован твой контраргумент?
Ты гуманитарий?
Ещё раз, для совсем одарённых: REST это стиль организации АПИ, интерфейса взаимодействия с твоей программой. Послал запрос, получил ответ, грубо говоря.
При этом запрос ты, сука такая, можешь составлять хоть в блокноте, а отвечать на него со стороны сервера будет гномик, выбирающий ответ в картотеке между ляжек твоей мамки.
И пока ты и гномик соблюдаете ряд условий -- у вас RESTful API, лол.
А сам гномик может быть "запрограммирован как угодно", это тебя, пидор с блокнотиком и запросами, вообще никак не ебёт.
В общем случае на стороне сервера, между интерфейсом (гномиком слушающим твои запросы) и непосредственным источником возвращаемых данных может быть пять слоёв абстракций и пара обращений к сервисам. И это, опять же, к RESTу уже никакого отношения не имеет. Ты сделал запрос GET-мамка/входящие, и это уже дело гномика сделать SQL запрос к расписанию мамки, или обратиться ко гномику поглубже, который знает лучше, или это монолитный мудрец-гном, который всё как мудак хранит в памяти, в синглтон объекте.
>если эти концепции в принципе друг другу не подходят.
Для особо одаренных: REST = interface
Ах да, и если ты реально написал свой первый хелловорлд на ООП-языке, и он у тебя плохо натянулся на REST-глобус, то изволь привести код и объяснить, где сове жмёт.
Анон поглядит, и пять к одному, что дело не в ООП
Не могу понять, неужели я так сложно объяснил суть моих претензий к спайке REST и ООП? Попробую еще раз. REST - это манипулирование данными через установку атрибутов ресурса, а ООП - через вызов методов ресурса (объекта). Способ манипулирования REST противоречит концепции инкапсуляции, принятой в ООП. Соединять их - ненатурально. Так зачем делать это?
Мне кажется со мной спорят аноны с синдромом утенка, у которых вызывает отторжение сама мысль, что есть и другие варианты.
Первый хелловорлд на ООП-языке я написал лет 18 назад.
Пример кода я привел в ОП-посте, сожалею что спустя 40 постов ты всё ещё не смог его осилить.
>Не могу понять, неужели я так сложно объяснил суть моих претензий к спайке REST и ООП? Попробую еще раз. REST - это манипулирование данными через установку атрибутов ресурса, а ООП - через вызов методов ресурса (объекта). Способ манипулирования REST противоречит концепции инкапсуляции, принятой в ООП. Соединять их - ненатурально. Так зачем делать это?
Инкапсулируются только те атрибуты, который необходимо инкапсулировать. Например такие, которые системные, нужны для работы класа.
Остальные атрибуты делаются публичными.
>ООП - через вызов методов ресурса (объекта)
Через вызов методов и аттрибутов объекта
> Пример кода я привел в ОП-посте, сожалею что спустя 40 постов ты всё ещё не смог его осилить.
> В ОП-посте описание REST интерфейса и ни строчки кода, ни класса, ни какой имплементации.
Знаешь, есть ты за 18 лет не разобрался в архитектуре сложнее однострочника, в котором хранилище данных и сетевой интерфейс как-то напрямую взаимодействуют, то всё очень-очень плохо
>REST - это манипулирование данными через установку атрибутов ресурса
Ну что за маняфантазии? Ты читал вообще что такое REST? Там ни слова про установку атрибутов ресурса, про то, что у ресурса должны быть какие-то атрибуты, а так же нет конкретного механизма изменения ресурса.
Мы вам перезвоним
Если в Json-REST API при запросе put ты не передаешь атрибуты ресурсу, то что ты передаешь?
>Ты читал вообще что такое REST? Там ни слова про
У РЕСТ нет спецификации, поэтому начнем с того, где "там".
И где ты увидел что я ресту приписываю конкретный механизм изменения ресурса. Свой вопрос я задал явно и конкретно, пиздоглазый утёнок.
РЕСТ - это набор ограничений для построения хорошего, годного АПИ и среди этих ограничений нет ничего подобного, о чем пишет ОП.
Это уже детали конкретной реализации. Это могут быть как атрибуты, так и любые другие сущности - команды, функции, действия и вообще какие угодно сущности. И если кто-то где-то нарушает инкапсуляцию, так это сам программист, который тупо выставил наружу все кишки своей программы, вместо того, чтобы придумать интерфейс.
Ты так и не ответил где "там".
>Это уже детали конкретной реализации. Это могут быть как атрибуты, так и любые другие сущности - команды, функции, действия
Опять нет конкретного ответа.
Если ты понятия не имеешь про РЕСТ, можно просто не захламлять эфир белым шумом.
>Ты так и не ответил где "там".
В определении REST и RESTful system, блять, тупое ты создание. Открой хотя бы википедию и прочти про это.
>Опять нет конкретного ответа.
А что конкретного можно ответить на твой абстрактный пример? Хуй знает какая там семантика у твоего JSON сообщения. Но, обычно, методом PUT заменяют коллекцию ресурсов, или один конкретный ресурс на другой. Но REST тебя к этому не обязывает.
>А что конкретного можно ответить
Что ответить не знает, но своё авторитетное мнение зачем-то пихает. Типичный школьник.
Мальчик мой, я в этой индустрии уже более 10 лет. И поверь мне, ты бы у меня даже джуном ни дня не продержался бы — моментально был бы уволен за некомпетентность. Так что прикрой свой ротешник и прекрати позориться.
LOL.
Вот тебе конкретный ответ: иди нахуй, пидор.
Поссал на твою мать, говно ЧСВшное.
GraphQL
Школьник подгорел.
Тролль, плез.
Школьник плез.
Сейчас рассматриваю его, и понимаю что не во всех случаях он нужен, REST/RPC проще и зачастую их хватает. Может я ошибаюсь, поправь. Алсо, что скажешь насчет GRPC?
bmup
> в REST глагол - только HTTP метод, в адресе же - всё существительное
Такое ограничение действительно не дает тебе использовать url для отправки сообщения объекту (если твой ресурс - объект). Но у меня возникает вопрос - откуда ты его взял? Я перечитал в вики 6 основных ограничений REST и не нашел там его.
> PUT /invitiations/:id
> {status: "accepted|refused"}
А чтение клиентом статуса в твоей системе возможно? Если да - то он у тебя все равно наружу торчит, вот такое вот ооп, лол.
Вообще тред очень жирный, спасибо, оп. Прям как ооп-треды в старые добрые времена почти.
Этот весь тред, на самом деле, полный пиздец. Пиздец как начиная с самого REST (если кто не в курсе - это всего лишь прикладной протокол поверх HTTP из которого смузипетушня сделала какую-то религию), так и с вопроса ОП хуя а не запрещено ли религией жрать свинину не противоречит ли протокол прикладного уровня объектно-ориентированному программированию.
>если кто не в курсе - это всего лишь прикладной протокол поверх HTTP из которого смузипетушня сделала какую-то религию
Причем, самая мякотка в том, что протокола на самом деле никакого нет - это по-сути просто такие сорт оф уголовные понятия (то есть определен только на словах, трактуемых каждым по-своему без какой-либо спецификации и механизмов валидации) про то как кошерно хипстопидору в 2к0Х-2к1X пердолить протокол HTTP.
> Если исходить из того, что пользуясь таким свойством ООП как инкапсуляция, мы скрываем от пользователя детали реализации (атрибуты), а публичный интерфейс объекта - это набор действий (методов), то встаёт вопрос о соответствии этой парадигмы записи в файл и чтению из файла.
> Ведь работа с файлами - это буквально о том, как ресурсу (файлу) пользователь устанавливает напрямую содержимое. Инкапсуляция, получается, идёт прямиком в жопу.
> Если исходить из того, что пользуясь таким свойством ООП как инкапсуляция, мы скрываем от пользователя детали реализации (атрибуты), а публичный интерфейс объекта - это набор действий (методов), то встаёт вопрос о соответствии этой парадигмы сетевому взаимодействию.
> Ведь сетевое взаимодействие - это буквально о том, как ресурсу (сокету) пользователь устанавливает напрямую передаваемые данные. Инкапсуляция, получается, идёт прямиком в жопу.
>REST (если кто не в курсе - это всего лишь прикладной протокол
Какой это тебе, нахуй, протокол? REST - набор ограничений, которые можно наложить хоть на HTTP, хоть на твою мамашу-шлюху, чтобы она превратилась в RESTFul web-service.
С файлами у тебя выбора нет в отличие от при.
В отличие от АПИ ёпт
> Но у меня возникает вопрос - откуда ты его взял? Я перечитал в вики 6 основных ограничений REST и не нашел там его.
Хм, его знают все, кто работает с рест. Это базовое отличие от RPC. Можешь заглянуть сюда например https://restfulapi.net/resource-naming/
>А чтение клиентом статуса в твоей системе возможно?
Клиентом чего, апи класса или апи, предоставляемом по сети как сервис?
Бамп
По ссылке дается определение ресурса, довольно четкое. Думаю, если ОП прочитает его, он больше не станет задавать идиотских вопросов.
>Хм, его знают все, кто работает с рест. Это базовое отличие от RPC. Можешь заглянуть сюда например https://restfulapi.net/resource-naming/
Результат заглядывания наглядно демонстрирует, что ты пиздишь:
>A controller resource models a procedural concept. Controller resources are like executable functions, with parameters and return values; inputs and outputs.
> Use “verb” to denote controller archetype.
Очевидно, ОП не умеет в логику, в русский и в ангельскийно скорее всего он простой тролль.
Все, кто использует PUT метод - макаки, ноу дискасс.
Я и есть ОП. Как видишь, учу РЕСТу местных макак, которые считают что они знают лучше меня лол.
Лол. Вы читали вообще ссылку?
Во-первых:
>Use nouns to represent resources
>RESTful URI should refer to a resource that is a thing (noun) instead of referring to an action (verb) because nouns have properties which verbs do not have – similar to resources have attributes.
Во-вторых, фрагмент "Use “verb” to denote controller archetype" относится к архетипу контроллер, а выше сказано:
>For uniformity’s sake, resist the temptation to design resources that are hybrids of more than one archetype.
Таким образом, или делаешь нормальный REST, или вот этот контроллер-архетип, который по сути является RPC. И даже слова "A controller resource models a procedural concept" вас не навели ни на какую такую мысль.
Ты неисправимый дегенерат. Даже после того, как тебя ткнули носом в твоё же дерьмо, ты продолжаешь лолкать и тупить дальше. Лучше бросай погромирование, не твое это (если ты не ребенок 15-25 лет, конечно - тогда еще есть шанс).
заходишь в тред: ОП продолжает обсираться который день подряд
По теме треда есть что сказать, обиженный ребёнок?
мимопроходил. Как рестом выразить "убить врага и забрать его деньги"?
Есть, да только ты не услышишь. Ты швырнул в меня текстом, в котором черным по белому написан ответ на твой вопрос, но ты неспособен его увидеть, так как вычитываешь из текста только, что, как тебе кажется, подтверждает твое поганое мнение.
Осилишь сам показать мне, где обосрался в своем последнем посте, чванливый кусок говна - я тебе помогу, нет - тебе уже никто не поможет, разве что кадровичка по приказу уставшего терпеть твои косяки руководства сделает за тебя то, на что у тебя самого не хватит яиц.
Пиздец ты ебанутый.
Для этого надо придумать некий ресурс, который ты якобы создаешь этим действием. Например, назвать такой ресурс action, и выразить действие как
POST /actions
{action_type: "kill_enemy_and_take_his_money", enemy_id: XXX}
POST /person/1/kill
Это переведет врага в статус "труп" и наделит текущего пользователя эксклюзивным правом распоряжаться своими зависимыми ресурсами.
POST /person/1/money/give
{"target" : /person/2}
Мертвый враг отдает деньги кому сказано.
Тебя тут английским языком призывают не смешивать два архетипа в одном ресурсе. А ты уже начал фантазировать, что контролер не подходит под определение REST.
Я бы сделал как то так:
POST /enemy/{id}/kill
В ответе:
"/corpse/{id}"
GET /corpse
В ответе:
{actions: ["/corpse/{id}/examine", "/corpse/{id}/dismember", "/corpse/{id}/burn" ...]}
GET /corpse/{id}/examine
["/item/{id}" ...]
POST /me/take
"/item/{id}"
в такой actions вообще всё можно запихнуть. И будет даже удобнее
>Я бы сделал как то так:
>POST /enemy/{id}/kill
>В ответе:
>"/corpse/{id}"
>
>GET /corpse
>В ответе:
>{actions: ["/corpse/{id}/examine", "/corpse/{id}/dismember", "/corpse/{id}/burn" ...]}
>
>GET /corpse/{id}/examine
>["/item/{id}" ...]
>
>POST /me/take
>"/item/{id}"
АЗАЗАЗАЗА СТЕЙТ НА СЕРВИРЕ, ТВОЙ РЕСТ НЕ РЕСТ))))))
Дурачок? Тебе стейты везде мерещатся?
Ждем STATELESS СУБД от любителей таких оладий
IMMUTABLE DB!
>{actions: ["/corpse/{id}/examine", "/corpse/{id}/dismember", "/corpse/{id}/burn" ...]}
Это процедуры, а не ресурсы. RPC, которое мечтает быть REST-ом.
ОП, тебя еще недостаточно обоссали за твои тупость и неумение читать? Ресурсу ничто не мешает быть процедурой.
Ну пока что ты ссышь себе в рот не переставая, почему меня это должно смущать. Сейчас ещё и обсеришься объясняя разницу между RPC и REST, а потом обмажешься несвежим говном рассказывая какие действия ты можешь сделать с процедурой как REST-ресурсом. Вперёд.
Хомячки возводят stateless в абсолют. REST всего-лишь ограничивает способ хранения стейта клиента: история взаимодействия с ресурсами, данные аутентификации итд. Сервер должен быть свободен от этого дерьма, а клиент должен сам нести свое бремя.
Ок. Покажи где такое написано в определение REST, что процедуры - не подмножество ресурса, и вообще так нельзя.
>Ведь REST - это буквально о том, как ресурсу (объекту) пользователь устанавливает напрямую атрибуты. Инкапсуляция, получается, идёт прямиком в жопу.
Нет. По-твоему и поля геттеры и сеттеры в жабе нарушают инкапсуляцию, хотя это не так: объект сам решит, апдейтить ему себя, или нет. Инкапсуляция была бы нарушена, если бы мы выдавали RPC с возможностью делать свои SQL-запросы. Тогда да.
REST - это о том, как передавать стейт через stateless протокол. Потому что по сути у тебя есть сервер, есть клиент, и там и там нужно хранить и синхронизировать состояние, а протокол HTTP stateless по разумным причинам. И нужен унифицированный подход, как это делать.
RPC не унифицирован, смотри на твоем примере: клиент залогинен с компа и телефона, на компе он вызывает RPC-процедуру принятия приглашения, ему придет ответ, мол, все ок, а телефон об этом как узнает? Никак. Поэтому помимо acceptInvitation()/refuseInvitation() тебе нужна будет функция getInvitationInfo(), и еще немного подумав ты сделаешь аналог REST, просто на RPC.
>Во-первых, для двух весьма разных действий имеется одна точка входа, что нарушает interface segregation principle.
Действие одно и то же - апдейт состояния ресурса. На клиенте ты сделал POST/PUT, апдейтнул, дальше сделал GET и юзер видит, как оно в итоге получилось. Разница только в том, что ты считаешь ресурсом - приглашение или какие-то отдельные его свойства.
>Правда REST подразумевает что такой ресурс будет существовать в какой-то истории, и мы сможем посмотреть список всех приемов и отказов данного приглашения (GET /invitations/:id/acceptations), хотя мы ожидаем только единоразовое действие, да и доступ к такому списку такой нам в принципе не нужен.
>Выглядит как натягивание совы на глобус ради чистоты парадигмы.
Наоборот. Клиент априори мудак и хацкер. Поэтому хранить его состояние как список его действий - это хороший и годный подход. Конечно, если у тебя хуйлоад это может быть избыточным, но в хранении списка всех приемов и отказов данного приглашения ничего плохого нет.
>что уже есть смешением REST и RPC: добираемся до нужного приглашения по REST, а инкапсулированное действие вызываем как RPC.
Ну так ты обзови это
PUT /invitations/:id/accepted
PUT /invitations/:id/refused
И это будет лучший способ.
>Не могу понять, неужели я так сложно объяснил суть моих претензий к спайке REST и ООП? Попробую еще раз. REST - это манипулирование данными
через установку атрибутов ресурса, а ООП - через вызов методов ресурса (объекта).
Не понятно, почему ты так дрочишь на ООП.
Нет, вот эти твои претензи - хуйня полная. ООП - это посылка сообщений объекту, который обладает внутренним состоянием. Объект не гарантирует, что он твое сообщение не выкинет. Он вообще тебе ничего не гарантирует. Потому что он инкапсулирован и у него лапки.
С REST то же самое. Послать сообщение серверу ты можешь. А все остальное инкапсулировано.
Поэтому концепции хорошо ложатся друг на друга. Ты просто считаешь, что у тебя объект один, приглашение. На самом деле у тебя объектов два - приглашение на клиенте и приглашение на сервере. И тебе нужно сделать так, чтобы у этих объектов было согласованное состояние. Поэтому если локально ты делаешь процедуру object.accept и object.refuse и не паришься, то при появлении посредника в виде HTTP у тебя появляются проблема передачи состояния.
Так что REST и ООП прекрасно работают. Другой вопрос, что ты не замечаешь других слонов, например ORM. Веб строится вокруг реляционных БД, которые на ООП натягиваются действительно очень хуево, потому что записи в БД на самом деле иммутабельны и меняются только после успешной транзакции.
Нормальные люди поняли, что ООП сдохнет еще в девяностые, в 2018 это не очевидно только непрофессионалам типа авторов книжек и преподавателей вузов. Гуйня когда-то была вотчиной ООП, сейчас в моде реактивность, С++ умер и остался только на высокопроизводительных приложениях, где используется dataflow-подход, веб становится асинхронным, в жабе от ООП осталось одно название. Из новых языков типа rust или go выпилено наследование. ООП это вообще не так вещь, относительно которой следует плясать и крутиться.
А своими мозгами подумать не хочешь? Чем этот "REST" отличает от "RPC" и какие манипуляции кроме call можешь над процедурой делать расскажешь?
>По-твоему и поля геттеры и сеттеры в жабе нарушают инкапсуляцию
Сеттеры нарушают безусловно. Жаба это в принципе кусок вонючего говна, ты зря решил её привести в пример.
>хотя это не так: объект сам решит, апдейтить ему себя, или нет
Если под "апдейтить" подразумевается что в методе-сеттере есть какая-то бизнес-логика, то это уже не сеттер, а бизнес-логика.
> смотри на твоем примере: клиент залогинен с компа и телефона, на компе он вызывает RPC-процедуру принятия приглашения, ему придет ответ, мол, все ок, а телефон об этом как узнает? Никак. Поэтому помимо acceptInvitation()/refuseInvitation() тебе нужна будет функция getInvitationInfo(), и еще немного подумав ты сделаешь аналог REST, просто на RPC.
И в чем проблема, в третьей функции? Как REST решает эту её? Можешь привести аналог на REST?
>Действие одно и то же - апдейт состояния ресурса.
Вот в этом месте как раз явно видно противоречие с принципом инкапсуляции. Для объекта это два разных пути развития бизнес-логики, с очень разными последствиями, будут вызваны два разных метода а для REST - всего лишь апдейт одного поля.
>в хранении списка всех приемов и отказов данного приглашения ничего плохого нет.
Оно просто НИНУЖНО. Нет такого требования в спецификации.
>RPC - это будет лучший способ.
Я о том и толкую, что RPC гораздо чаще удобней чем REST, а у местных утят дупа горит от мысли что на швитой REST покусились. Ну молодец что первым допетрил логически.
>На самом деле у тебя объектов два - приглашение на клиенте и приглашение на сервере. И тебе нужно сделать так, чтобы у этих объектов было согласованное состояние.
>Нет нарушения инкапсуляции
Ты наверно и в ОО-коде вместо методов бизнес-логики вызываешь сеттеры из любого места ¯\_(ツ)_/¯
>А своими мозгами подумать не хочешь? Чем этот "REST" отличает от "RPC" и какие манипуляции кроме call можешь над процедурой делать расскажешь?
Ясно-понятно. Найти такого ограничения на ресурс не можешь. Если ты сам себя убедил в том, что ресурс - это ООП объект с кишками наружу, то это не значит, что это действительно так и есть.
Что касается разницы RPC и REST, то она чисто семантическая.
POST /enemy/{id}/kill в RPC означает вызов процедуры, а в REST - создание нового ресурса.
rpc типа wsdl: есть чёткое описание методов, параметров, ответа
rest: нет даже списка методов и возможных операций.
Можно ли делать put на "товар" - хуй знает. Что оно на самом деле делает - хуй знает
Сравните addPurchareToBacket(purchare, basket) - всё просто и понятно. А как через рест? Пут или пост? Корзина или товар?
rest: нет даже списка методов и возможных операций.
Можно ли делать put на "товар" - хуй знает. Что оно на самом деле делает - хуй знает
Сравните addPurchareToBacket(purchare, basket) - всё просто и понятно. А как через рест? Пут или пост? Корзина или товар?
Все уже разжевано по твоей же ссылке вдоль и поперек, твоя клоунада выглядит жалко. Тебя уже несколько человек в говно макнули, сколько тебе еще надо?
>Можно ли делать put на "товар" - хуй знает.
Знатоки, блять, REST over HTTP собрались тут.
Есть запрос специальный. Называется OPTIONS, который и вернет тебе требуемое описание, или даже кусок кода.
зачем вообще бизнес-логику пытаться натягивать на транспортный протокол? Давай тогда сразу tcp командами хуячить
> в жабе от ООП осталось одно название
Можешь пояснить для моего общего развития?
>HTTP
>транспортный протокол
Сам поймешь где обосрался, или носом тыкнуть?
тыкни. Знаешь что такое бизнес-логика?
>тыкни
HTTP - это протокол прикладного уровня.
>Что касается разницы RPC и REST, то она чисто семантическая.
>POST /enemy/{id}/kill в RPC означает вызов процедуры, а в REST - создание нового ресурса.
Лол бля. Включай мозги, просвещайся.
https://www.smashingmagazine.com/2016/09/understanding-rest-and-rpc-for-http-apis/
Ну вот ты и пожрал говна, поздравляю.
Ну зойчем ты себя каждый раз макаешь в дерьмо? Ты мазохист чтоле?
Из твоей же ссылки:
>RPC. We are sending a message, and that might end up storing something in the database to keep a history, which might be another RPC call with possibly the same field names — who knows?
>REST. We are creating a message resource in the user’s messages collection. We can see a history of these easily by doing a GET on the same URL, and the message will be sent in the background.
Говноед, ты обдристался с ответами на два простых вопроса. Зачем ты продолжаешь есть говно?
Всё с тобой ясно, дебил, который не может в конструктив.
Ай лолд. Говноед, ты когда на два банальных вопроса ответишь, получишь разрешение кукарекать про конструктив.
Нахуй иди, упоротый мудак.
>HTTP
HTTP (англ. HyperText Transfer Protocol — «протокол передачи гипертекста») — протокол прикладного уровня передачи данных (изначально — в виде гипертекстовых документов в формате «HTML»
Протокол передачи html страничек
>Сеттеры нарушают безусловно.
Нет. Нарушением инкапсуляции будет выставление публичных полей, когда объект не может проконтролировать пенетрацию в свое нежное тельце. Когда у тебя есть сеттер, сегодня он просто выставляет поле, завтра форматирует жесткий диск, тот, кто посылает сообщение объекту об этом не знает.
>Если под "апдейтить" подразумевается что в методе-сеттере есть какая-то бизнес-логика, то это уже не сеттер, а бизнес-логика.
Ты можешь назвать ее йобампампацией, суть не изменится: вызывая йобампампацию ты не нарушаешь инкапсуляцию. Чтобы ее нарушить, нужно сделать публичным поле объекта. В случае HTTP аналог это дать доступ писать непосредственно в БД на сервере.
Для какого-нибудь научного сервера в локальной сети для своих это может вполне работать, кстати - ну нет у людей ресурсов держать человека, который будет транслировать операции БД в API-запросы, но это очевидное нарушение инкапсуляции.
>И в чем проблема, в третьей функции? Как REST решает эту её? Можешь привести аналог на REST?
Это и есть REST.
Ты путаешь синтаксис и семантику и считаешь, что REST - это когда урлы со слэшами, а RPC - это когда глагол английского языка с json'ом в виде параметров. А суть в другом. Если у тебя в твоем "RPC" acceptInvitation(invitation_name)/refuseInvitation(invitation_name) и getInvitationInfo(invitation_name), ты навелосипедил REST. У тебя 3 функции, которые делают update и read операции, принимающие один основной параметр - имя ресурса.
>Вот в этом месте как раз явно видно противоречие с принципом инкапсуляции. Для объекта это два разных пути развития бизнес-логики, с очень разными последствиями, будут вызваны два разных метода а для REST - всего лишь апдейт одного поля.
Принцип инкапсуляции заключается в том, что клиент понятия не имеет, что это для объекта. Он просит его апдейтнутся, объект это делает.
>Оно просто НИНУЖНО. Нет такого требования в спецификации.
Заказчик не обязан учитывать все. Это ты как программист должен заранее сделать так, чтобы код не пришлось потом переделывать.
>Я о том и толкую, что RPC гораздо чаще удобней чем REST, а у местных утят дупа горит от мысли что на швитой REST покусились. Ну молодец что первым допетрил логически.
Наиболее часто RPC это такой хуевый способ описать REST API с рандомными названиями интерфейсов.
Я сам С++ программист и делаю в основном RPC-сервисы, потому что вся моя работа это обслуживать быстрым сервером медленных клиентов. И RPC поверх stateless протокола (HTTP) хорош как раз в этом случае, когда каждый call у тебя является чистой функцией, или же там передается простенькая кука типа токена авторизации, чтобы я на сервере мог проверить, например, оплатил ли клиент услуги, но, что важно, я не шарю состояние клиенту.
Когда же нужно шарить состояние между удаленными системами, альтератив REST'у я не вижу. ты все равно к нему придешь.
Все, заебись. И тут блядь ты смотришь и видишь, что process - это create, update - update, getresult - read, а stop - это delete, а весь твой API крутится вокруг ресурса job. Только программист, который будет читать твой API подумает "блядь, ну ведь RESTful же морда, не могли сделать без этих ебанутых названий методов?". Собственно и ты предлагаешь то же самое. Взять RESTful интерфейс и реализовать его на RPC.
То, что ты доебался до того, что "сеттеры нарушают инкапсуляцию" и "глаголы в REST использовать зашквар" - это гуманитарные доебки. Ну да, вместо post invitation/accept надо делать post invitation/accepted, суть-то API не меняется, у тебя есть ресурс, ты хранишь его состояние и передаешь. Хоть азбукой Морзе его передавай, есть два способа сделать это - REST и велосипедный говнорестподобный кал.
>Ты наверно и в ОО-коде вместо методов бизнес-логики вызываешь сеттеры из любого места ¯\_(ツ)_/¯
Если сеттер - часть публичного API, в чем проблема?
Естественно в локальном коде надо делать invitation.setState(invitation::State::REFUSED), а не пилить толпу методов с какими-то неочевидными названиями. Потому что изменения состояния штука плохая и оно чем более оно явно, тем лучше. Инкапсуляция при этом не нарушается, потому что объект не обязан менять свое состояние по моему приказу. Если внутри setState есть бизнес-логика, ничего плохого в этом нет. Это нормально - если бы в сеттерах не нужна была бы логика, они бы не были нужны изначально, выставляешь публичные поля и все, зачем заморачиваться.
По сути твой invitation это конечный автомат с двумя состояниями, если вдруг окажется, что число состояний у объекта вырастет (к accepted/refused будет добавлено delayed, banned например и т. д.), твое API начнет раздувать от тонны разных методов и непонятных взаимоотношений между ними. А здесь ты сможешь обойтись одним методом setState и enum'ом с типами стейтов, в котором он может быть.
Дальше по-хорошему нужно вспомнить, что состояние - говно, от которого нужно избавляться и ресурсом иметь
1. invitation
2. список accept'ов и refuse'ов
И станет совсем хорошо.
ООП - объекты с внутренним состоянием, обменивающиеся сообщениями. Годится для моделирования всяких систем.
В жабе у тебя будет https://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.html
Там большей частью объекты и интерфейсы костыли для странной системы типов жабы, а сам код вообще не ООП
И как это противоречит тому, что я сказал, и подтверждает твой тезис, что это транспортный протокол?
>Все, заебись. И тут блядь ты смотришь и видишь, что process - это create, update - update, getresult - read, а stop - это delete, а весь твой API крутится вокруг ресурса job. Только программист, который будет читать твой API подумает "блядь, ну ведь RESTful же морда, не могли сделать без этих ебанутых названий методов?". Собственно и ты предлагаешь то же самое. Взять RESTful интерфейс и реализовать его на RPC.
Тут выше кусок текста пропал. Короче суть в том, что я знаю, что у меня будет process(token, parameters), потому что сервис квази-реалтаймовый.
Но если бы он был оффлайновым, то простой вызов process(authorization_token, parameters) превратится в
process(authorization_token, parameters) : job_id
update_parameters((authorization_token, job_id, parameters)
getresult((authorization_token, job_id)
stop(job_id) и далее ты обнаруживаешь, что навелосипедил REST.
Пример: https://vk.com/dev/methods . Типичный RPC.
Есть account.saveProfileInfo, есть account.setInfo, а есть setNameInMenu и прочая хуита, которая не логична и выросла просто из того, что кто-то в самом начале поленился сделать REST
Транспортный протокол называется TCP/IP. HTTP - прикладной протокол, довольно высокоуровневый. То, что его превратили в "GET когда параметры в запросе и POST когда параметры хочешь скрыть" - это печально.
>его превратили в "GET когда параметры в запросе и POST когда параметры хочешь скрыть"
Настало время охуительных историй.
А куки в заголовках, так вообще пиздец?
Не, с авторизацией в http проеб, кривожопая она
>Нет. Нарушением инкапсуляции будет выставление публичных полей, когда объект не может проконтролировать пенетрацию в свое нежное тельце. Когда у тебя есть сеттер, сегодня он просто выставляет поле, завтра форматирует жесткий диск, тот, кто посылает сообщение объекту об этом не знает.
>Ты можешь назвать ее йобампампацией, суть не изменится: вызывая йобампампацию ты не нарушаешь инкапсуляцию. Чтобы ее нарушить, нужно сделать публичным поле объекта.
Ок, согласен. Тогда, если по REST API пришел запрос PUT /resource {status: X, quantity: Y}, и сеттер поля status форматирует жесткий диск, а сеттер quantity просто устанавливает int поле, это норм с ООП сочетается?
>В случае HTTP аналог это дать доступ писать непосредственно в БД на сервере.
БД никак не относится к HTTP. REST API может быть не только по HTTP. Незачет.
>Ты путаешь синтаксис и семантику и считаешь, что REST - это когда урлы со слэшами, а RPC - это когда глагол английского языка с json'ом в виде параметров.
Я считаю что REST это [HTTP/FTP/anything] action verb + URI noun. >Если у тебя в твоем "RPC" acceptInvitation(invitation_name)/refuseInvitation(invitation_name) и getInvitationInfo(invitation_name), ты навелосипедил REST. У тебя 3 функции, которые делают update и read операции, принимающие один основной параметр - имя ресурса.
Это не REST. Ты возможно путаешь REST с CRUD. Наличие в URL глагола является маркером RPC.
>Принцип инкапсуляции заключается в том, что клиент понятия не имеет, что это для объекта. Он просит его апдейтнутся, объект это делает.
Он просит его апдейтнуться, а объект форматирует жесткий диск. Охуенное наложение концепций.
>Заказчик не обязан учитывать все. Это ты как программист должен заранее сделать так, чтобы код не пришлось потом переделывать.
Это не обосновывает что я должен дизайнить код и базу под твою личную хотелку хранения списка приемов/отказов.
>Когда же нужно шарить состояние между удаленными системами, альтератив REST'у я не вижу
Т.е. когда надо поформошлепить. Когда бизнес-логика выходит за пределы банального CRUD, придумываються отмазки "эта процедура не процедура, а ресурс".
>вместо post invitation/accept надо делать post invitation/accepted, суть-то API не меняется
Если суть не менялась бы, не было бы отдельно REST и отдельно RPC.
протокол для передачи данных. Он ничего не знает про твою бизнес-логику
Это протокол позволяет выразить твою бизнес логику в терминах HTTP запрос/ответ.
Причем протокол написан так, что клиент может вообще нихуя не знать об API сервиса, но запросив базовый урл, узнать все, что нужно для движения дальше, вплоть до получения исполняемого кодабраузеры с js, сука, так и работают.
>поленился
ПОЛЕНИЛСЯ
посоны, мать его в сраку, ПОЛЕНИЛСЯ
А не ленился, то в бинарных кодах бы написал
>Это протокол позволяет выразить твою бизнес логику в терминах HTTP запрос/ответ.
а с помощью tcp так сможешь? Там тоже куча кодов, которых можно привзять к бизнес-логике
>Ок, согласен. Тогда, если по REST API пришел запрос PUT /resource {status: X, quantity: Y}, и сеттер поля status форматирует жесткий диск, а сеттер quantity просто устанавливает int поле, это норм с ООП сочетается?
Если семантика поля status такова, почему нет? Если хочется соблюсти "один запрос - одно действие" - ну так запрети послылать
PUT /resource {status: X, quantity: Y}, и возвращай 500, а только PUT /resource {status: X} и PUT /resource {quantity: Y} отдельно. Это будет правильно, потому что тогда можно будет возвращать там 200 или 500. Но городить saveProfileInfo, setInfo, setNameInMenu, как в апи вконтактика - это так себе идея. Я вот только что туда заглядывал и уже забыл, чем saveProfileInfo отличается от setInfo.
>Я считаю что REST это [HTTP/FTP/anything] action verb + URI noun
REST это URI и действия над ним с кучей полезных ограничений, которые составляют лучшие практики при проектировании веб-сервисов.
RPC это все, что угодно в формате запрос-ответ (не берем какие-то стриминговые йобы или еще какую-то еботу). Естественно, "все, что угодно" заведомо мощнее "URI и действия над ним". RPC может быть stateful и требовать каких-то изощренных протоколов (сначала вызовите malyYoba, потом bolshoYoba, если наоборот, работать не будет), RPC может одновременно апдейтить 20 объектов и тому подобное. А какие части речи при этом используют - это уже лингвистика.
Ты как рассуждаешь.
bool peka = false;
bool isYoba = true;
Вот isYoba - это boolean, ведь переменная начинается с глагола is. А peka - это не boolean, ведь это существительное, а как существительное может быть предикатом? Бред, от смены названия семантика не меняется, максимум становится менее понятной.
Суть в том, что принимая эти ограничения, ты создаешь простой, понятный и легко поддерживаемый API. А на практике случается всякое.
>Это не REST. Ты возможно путаешь REST с CRUD
Не путаю.
>Он просит его апдейтнуться, а объект форматирует жесткий диск. Охуенное наложение концепций.
ООП не запрещает побочные эффекты при апдейте внутреннего состояния объекта
>Т.е. когда надо поформошлепить. Когда бизнес-логика выходит за пределы банального CRUD, придумываються отмазки "эта процедура не процедура, а ресурс".
Все наоборот. Когда у тебя маленькие stateless GET-методы, можно не ебать мозг и сделать RPC API, возможно даже с какими-то протоколами типа "сначала вызовите malyYoba, потом bolshoYoba". Чем больше и сложнее у тебя ресурс, тем больше ты будешь страдать о того, что интернет - это не твоя локальная машина, а объекты твоей предметной области могут быть раскиданы по всему глобусу. И тут до тебя доходит, как разложить твою задачу на CRUD.
>Если суть не менялась бы, не было бы отдельно REST и отдельно RPC.
А они не отдельно. Это непрерывный спектр различных возможностей.
>Там тоже куча кодов, которых можно привзять к бизнес-логике
Не-а
Это еще мягко сказано. Вконтакте написан на пхп криворукими обезьянами, которые до сих пор не сделали нормальный поиск музыки.
>сначала вызовите malyYoba, потом bolshoYoba, если наоборот, работать не будет
POST /enemy/{id}/kill
В ответе:
"/corpse/{id}"
GET /corpse
В ответе:
{actions: ["/corpse/{id}/examine", "/corpse/{id}/dismember", "/corpse/{id}/burn" ...]}
GET /corpse/{id}/examine
["/item/{id}" ...]
POST /me/take
"/item/{id}"
>а с помощью tcp так сможешь?
Если ты думаешь, что tcp находится на том же уровне абстракции, что и http, то у меня для тебя плохие новости.
они оба нужны для передачи данных. При этом их служебные команды нельзя использовать в каких-то других целях.
Например 404 всегда должно означать отсутствие ресурса по такому адресу, но никак не отсутствие пользователя или что у него нет денег
В данном случае ты не сможешь запросить ресурсы в обратном порядке вообще никак. Потому что ты не знаешь о существующем ресурсе. Так что мимо. А в рпц сможешь.
Application layer нужен для передачи данных между приложениями, или кусками приложения. В то время как TCP выполняет крайне низкоуровневую задачку по гарнтированной доставке вообще любых данных.
>Например 404 всегда должно означать отсутствие ресурса по такому адресу, но никак не отсутствие пользователя
Если пользователь, или деньги абстрагированы до понятия ресурс, то почему нет?
как ты отличишь реальный 404 от "нет пользователя"?
>Если хочется соблюсти "один запрос - одно действие"
Не "хочется", а это суть ООП, для этого придумали композицию объектов.
>ну так запрети послылать
PUT /resource {status: X, quantity: Y}, и возвращай 500, а только PUT /resource {status: X} и PUT /resource {quantity: Y} отдельно
Единая точка входа для кучи разномастных действий. Контроллер, который владеет информацией о внутреннем устройстве моделей, знает какие действия можно сочетать, какие нет. Звучит просто кайф.
>Не путаю.
Путаешь.
>ООП не запрещает побочные эффекты при апдейте внутреннего состояния объекта
Качество твоего ООП-кода понятно. Только "Он просит его апдейтнуться, а объект форматирует жесткий диск" - это пиздец. Если тебе надо форматировать жетский диск, ты просишь форматировать, а не апдейтиться.
>Все наоборот.
Нет не наоборот. Всё, что в КРУД (который путаешь с РЕСТ) не попадает, требует искуственных извращений, которые описаны в ОП-посте.
Вот такой говнокод например
В котором можно сделать сначала /dismember, потом /burn, но никак не наоборот. Такой-то stateless REST.
Define "реальный 404"
Если ты имеешь ввиду что-то типа:
GET /users/1
404
То, прежде чем попасть по этому урлу, ты должен был зайти на
GET /users
OK
В таком случае нет юзера.
А в таком:
GET /users
404
Тебе бы вообще не следовало соваться в GET /users/1
>Это процедуры, а не ресурсы. RPC, которое мечтает быть REST-ом.
Ему нужно вынести глаголы в параметры запроса. Убийство это не POST, а DELETE с возвратом URI трупа.
>DELETE /enemy/{id}?kill
>В ответе:
>"/corpse/{id}"
GET /corpse/{id}?examine //на самом деле не так уж нужно, можно по дефолту показывать стейт
["/item/{id}" ...]
И так далее.
Еще он заморочился на самодокументировании, там я бы указал, что GET поддерживает одни параметры, POST другие. В целом нормально.
Алсо, отсутствие VERB в
>В ответе: {actions: ["/corpse/{id}/examine", "/corpse/{id}/dismember", "/corpse/{id}/burn" ...]}
как бы намекает что это не ресурсы, к которым еще необходимо применить какое-то действие, а вызов процедуры, которой похуй действие, ведь в RPC действие только одно - вызов.
>В ответе: {actions: ["/corpse/{id}/examine", "/corpse/{id}/dismember", "/corpse/{id}/burn" ...]}
как бы намекает что это не ресурсы, к которым еще необходимо применить какое-то действие, а вызов процедуры, которой похуй действие, ведь в RPC действие только одно - вызов.
>В котором можно сделать сначала /dismember, потом /burn, но никак не наоборот. Такой-то stateless REST.
Это список доступных действий, а не последовательность, лол.
>Ему нужно вынести глаголы в параметры запроса. Убийство это не POST, а DELETE с возвратом URI трупа.
И все, кто не были синхронно оповещены о создании corpse, больше никогда не найдут enemy по его id.
Вопрос со звездочкой: если DELETE - это убить, как реализовать ранение?
Т.е. можно расчленить труп, который ранее был сожжен?
>DELETE с возвратом URI трупа.
Ебать, с кем я на одной борде сижу. Какой возврат URL после DELETE? Ничего не попутал?
По вызову /enemy/{id} после kill может быть, например, 301 MOVED PERMANENTLY /corpse/{id}, а может OK и в каком-нибудь поле будет killed.
>Какой возврат URL после DELETE? Ничего не попутал?
Твоё же говнецо:
>DELETE /enemy/{id}?kill
>В ответе:
>"/corpse/{id}"
>запрос к DELETED ресурсу
>301 MOVED PERMANENTLY
>а может OK
>Т.е. можно расчленить труп, который ранее был сожжен?
А если его кто-то другой сжёг между твоими get и post? Если действие более недоступно, то возвращается 406. А по новому get вернется новый список действий, например.
>И все, кто не были синхронно оповещены о создании corpse, больше никогда не найдут enemy по его id.
Ну тащемта он убит
>Вопрос со звездочкой: если DELETE - это убить, как реализовать ранение?
Ранение меняет стейт, значит PUT
В чем проблема? DELETE может возвращать body, и там можно дать на ссылку с трупом, а остальным уже возвращать 404.
Мое говнецо было с POST, то говнецо другого анона.
URL созданного ресурса возвращается в Header Location, который с DELETE не используется.
Но это жы REST, там в принципе не может быть такого как в RPC
>RPC может быть stateful и требовать каких-то изощренных протоколов (сначала вызовите malyYoba, потом bolshoYoba, если наоборот, работать не будет)
>Не "хочется", а это суть ООП, для этого придумали композицию объектов.
Нет. Когда ты сразу кучу вещей апдейтишь разом, это - транзакция, и это удобно, особенно когда у тебя ресурс может апдейтиться конкурентно.
Типа, допустим ты редактируешь статью на википедии, и что, посылать изменение каждого поля отдельным запросом? Охуенно будет, когда 2 человека начнут что-то делать одновременно.
>Единая точка входа для кучи разномастных действий. Контроллер, который владеет информацией о внутреннем устройстве моделей, знает какие действия можно сочетать, какие нет.
Утверждение уровня "http-сервер знает о внутреннем устройстве моделей". С чего ты взял?
>Путаешь.
Нет, не путаю.
>Качество твоего ООП-кода понятно.
Я не пишу ООП код, я унижал ООП-манек на бордах еще в 2010.
>Всё, что в КРУД (который путаешь с РЕСТ) не попадает, требует искуственных извращений, которые описаны в ОП-посте.
Там нет каких-то извращений. Стоило только немного напрячь мозг и ты пришел к правильному решению.
>В котором можно сделать сначала /dismember, потом /burn, но никак не наоборот
Нельзя. После /burn ресурс просто не вернет тебе в списке actions dismember.
>>И все, кто не были синхронно оповещены о создании corpse, больше никогда не найдут enemy по его id.
>Ну тащемта он убит
И к профилю убитого доступа больше нет. Вся информация об убитом становится недоступной, ведь он удолен как ресурс.
>>Вопрос со звездочкой: если DELETE - это убить, как реализовать ранение?
>Ранение меняет стейт, значит PUT
PUT для идемпотентных запросов. Ещё попытка.
>Но это жы REST, там в принципе не может быть такого как в RPC
Какого такого?
Stateful означает существование разделяемого состояние клиент-сервер. Stateless - сервер не знает о состоянии клиента, клиент с каждым запросом ему сообщает все, что серверу требуется для обработки запроса, куки-хуюки. Это все не мешает быть самому серверу stateful.
>Я не пишу ООП код, я унижал ООП-манек на бордах еще в 2010.
Егорку хоть уважаешь?
>PUT для идемпотентных запросов
Уверен?
>И к профилю убитого доступа больше нет. Вся информация об убитом становится недоступной, ведь он удолен как ресурс.
Ну да. Ты мертвых видел когда-нибудь?
>PUT для идемпотентных запросов.
А ты помимо установления флага "ранен" хочешь уменьшать его банковский аккаунт на величину урона? Ну так ТЗ надо изначально грамотно составлять.
>Define "реальный 404"
сервак упал, или приложуха удалена
Если сервак упал, у тебя будет таймаут (408), приложуха упала - это 500
приложуха не задеплоена - 404
>>Не "хочется", а это суть ООП, для этого придумали композицию объектов.
>Нет. Когда ты сразу кучу вещей апдейтишь разом, это - транзакция, и это удобно, особенно когда у тебя ресурс может апдейтиться конкурентно.
Ты сперва написал `Если хочется соблюсти "один запрос - одно действие"`, а теперь - `Когда ты сразу кучу вещей апдейтишь разом, это - транзакция`.
Так вот. Один запрос HTTP - одно действие (метод) бизнес-логики. Когда по REST API присылают набор атрибутов, и для установки каждого вызывается отдельный сеттер с бизнес-логикой внутри - это кусок вонючего говна. Потому что правил о том, какие атрибуты можно присылать вместе, а какие нет, и в каком порядке - их нет. А если их делать, то нахуя этот цирк нужен.
>>Единая точка входа для кучи разномастных действий. Контроллер, который владеет информацией о внутреннем устройстве моделей, знает какие действия можно сочетать, какие нет.
>Утверждение уровня "http-сервер знает о внутреннем устройстве моделей". С чего ты взял?
Если в моделях меняется логика, и сеттеры, который раньше вызывались в порядке A->B, больше в таком порядке вызываться не могут, то потребуется в контроллере менять логику проверки присланных данных. http-сервер менять не придется.
>Я не пишу ООП код, я унижал ООП-манек на бордах еще в 2010.
Понятно что с таким качеством кода тебя выгнали на мороз еще в 2010.
>Там нет каких-то извращений.
Ну опять же хорошо что тебя с 2010 не подпускают к коду.
>>В котором можно сделать сначала /dismember, потом /burn, но никак не наоборот
>Нельзя. После /burn ресурс просто не вернет тебе в списке actions dismember.
Правильно. Если хочешь сделать в одной сессии оба действия, так и будет, а если в разных - WRONG. Такой-то stateless, REST порешал проблему присущую лишь RPC.
А клиента ебет, почему он не может получить свою конфетку?
>>Но это жы REST, там в принципе не может быть такого как в RPC
>Какого такого?
Ты слепошарый? Повторяю цитату какого:
>RPC может быть stateful и требовать каких-то изощренных протоколов (сначала вызовите malyYoba, потом bolshoYoba, если наоборот, работать не будет)
Уверен.
>Ну да. Ты мертвых видел когда-нибудь?
И видел, и имена их помню, и к вещам их у меня доступ есть. Включи башку:
DELETE /player/X -> Ok
GET /player/X/profile -> 404
>А ты помимо установления флага "ранен" хочешь уменьшать его банковский аккаунт на величину урона? Ну так ТЗ надо изначально грамотно составлять.
Давай составим. Надо нанести ранение с определенной силой. У игрока, которого ранят, отнимется энергия на величину зависящую от силы ранения и каких-то его внутренних состояний. Вперёд.
>Ты сперва написал `Если хочется соблюсти "один запрос - одно действие"`, а теперь - `Когда ты сразу кучу вещей апдейтишь разом, это - транзакция`.
Ну да. Хочется так - делаешь так, хочется так - делаешь так. Это не религиозные догматы.
Это ты пытаешься кому-то что-то запретить, теперь, оказывается, разные поля ресурса нельзя апдейтить одним запросом. Реальный мир устроен не так и шаблоны не загоняется. Ты скажи, что конкретно тебе нужно и тогда можно будет подумать, что можно сделать. Как в примере с трупом. А не какие-то абстрактные контроллеры, реализацию которых не ты видишь через жопу, а я в чем-тоне прав.
>Один запрос HTTP - одно действие (метод) бизнес-логики
Ну то есть статья на википедии должна модифицироваться серией POST запросов, сначала меняем заголовок, потом тело статьи, потом имя автора и т. д.
Или же юзера нужно обязать менять сразу все - статья на мегабайт, нужно поменять заголовок, но нет, мы будет гонять весь ее текст по сети.
>Понятно что с таким качеством кода тебя выгнали на мороз еще в 2010.
У меня неплохой код, я же не пишу ООП
>Если хочешь сделать в одной сессии оба действия, так и будет, а если в разных - WRONG.
Где ты сессии взял. У нас есть запросы и все. Если они разнесены во времени, то проблем нет. Если они идут одновременно, например
1. юзер1 делает get
2. юзер2 делает get
3. юзер1 вызывает метод1 и меняет стейт
4. юзер2 вызывает метод2 и меняет стейт, а он больше ресурсом не поддерживается
То юзер2 получит ошибку в лоб. Се ля ви.
А если ты хочешь, чтобы такого не было, пили полностью stateless систему, которая возвращает новые URI в ответ на юзерские модификации.
>Такой-то stateless, REST порешал проблему присущую лишь RPC.
Проблему конкурентности решают только транзакции, которые по твоим догмам делать нельзя
А давай ты нахуй пойдешь? Ты напоминаешь хуя с видео про иммолейт импрувед. Ох ебать, я не знаю какие-то тонкости HTTP, перепутал запросы и земля налетит на небесную ось. Ага.
Программист может совершить какие-то архитектурные ошибки, но это не выбор между PUT, POST или даже GET?action="apdeyt". Это вообще похуй.
>приложуха не задеплоена
500 - 504, выбирай любое.
>Ты слепошарый? Повторяю цитату какого:
А ты?
Повторяю цитату ответа:
>Stateful означает существование разделяемого состояние клиент-сервер. Stateless - сервер не знает о состоянии клиента, клиент с каждым запросом ему сообщает все, что серверу требуется для обработки запроса, куки-хуюки. Это все не мешает быть самому серверу stateful.
>Это ты пытаешься кому-то что-то запретить
LOL.
>Ты скажи, что конкретно тебе нужно
С чего ты взял что мне что-то конкретно нужно.
>>Один запрос HTTP - одно действие (метод) бизнес-логики
>Ну то есть статья на википедии должна модифицироваться серией POST запросов, сначала меняем заголовок, потом тело статьи, потом имя автора и т. д.
Статья на википедии это формошлепство, оно неинтересно и тут REST делает своё дело. Можешь пофантазировать с примером убийства и ранения игрока.
>>Если хочешь сделать в одной сессии оба действия, так и будет, а если в разных - WRONG.
>Где ты сессии взял.
Вот где:
>>Нельзя. После /burn ресурс просто не вернет тебе в списке actions dismember.
>После /burn
>После /burn
>После /burn
>транзакции, которые по твоим догмам делать нельзя
Это не мои догматы, а твои фантазии, транзакций даже не касался.
>>Такой-то stateless, REST порешал проблему присущую лишь RPC.
>Проблему конкурентности решают только транзакции
Откуда ты проблему конккурентности уже высрал? Речь о проблеме с этиъ твоих слов
>RPC может быть stateful и требовать каких-то изощренных протоколов (сначала вызовите malyYoba, потом bolshoYoba, если наоборот, работать не будет
После /burn ничем не напоминает.
Говнокодер подгорел.
>А если их делать, то нахуя этот цирк нужен.
Сеттеры и геттеры - это, как правило, само по себе говно вне предметной области задачи. Какая архитектура у приложухи, такое и РЕСТ АПИ.
Ну только эта цитата никак не объясняет почему RPC-шное
>сначала вызовите malyYoba, потом bolshoYoba, если наоборот, работать не будет
богомерзко, а REST-вое
>После /burn ресурс просто не вернет тебе в списке actions dismember.
где этот список actions надо откуда-то высирать, если /burn вызывал не ты и/или не сейчас - это благодать.
Теперь осталось проложить мостик между "сеттеры говно" и "REST юзает сеттеры".
>где этот список actions надо откуда-то высирать,
Ну что ты такой тугой-то?
Когда ты попросишь (давно известный тебе) POST /enemy/1/burn ,тебе вернется 410, и если ты все еще хочешь поизмываться над трупом, то тебе придется запросить, GET /enemy/1, а в ответ придет 200 {actions: ["collect_ash"], status: "burned"}
Тут есть мостики только в головах ООП-даунов. REST совсем не о сеттерах и геттерах.
Лишний запрос делать? Круто.
>POST /enemy/1/burn
POST-запрос создаёт ресурсы. Какой ресурс ты создаешь в данном случае, сжигание? Т.е. одному enemy в качестве вложенных ресурсов может принадлежать 1 сжигание, 1 расчленение, 1 повешение, 1 утопление в кислоте и так далее.
Т.к. этих ресурсов может быть только по одному, то создание их идемпотентно, значит использовать надо PUT /enemy/1/burn вместо POST, не?
Когда захотим проверить есть ли у enemy тот или иной ресурс, будем проверять наличие вложенного ресурса пока не наткнемся на один из:
GET /enemy/1/burn
GET /enemy/1/dismember
GET /enemy/1/hang
GET /enemy/1/aciddrown
Круто, чо.
>actions: ["collect_ash"]
Какой и почему HTTP метод? Как называется данный ресурс? (подсказка: это не ресурс, а процедура, с ней можно сделать только одно действие - вызвать, поэтому HTTP метод и не указан. RPC, которое утята считает REST кек).
Долбоёб, тред называется "REST vs OOP".
>LOL.
Перечитай свои посты. Такой проповедник с кучей догматов.
>С чего ты взял что мне что-то конкретно нужно.
Ну если тебе ничего не нужно, зачем ты что-то пишешь? Удобная позиция, как только тебе задают конкретику "ой мам, я тут тралю на самом деле".
>Статья на википедии это формошлепство, оно неинтересно и тут REST делает своё дело.
Логическая уловка "ненастоящий шотландец". Пакетное изменение свойств это банальная вещь, и принципиально это от убийства и ранения не отличается - модифицируется стейт.
>Откуда ты проблему конккурентности уже высрал? Речь о проблеме с этиъ твоих слов
Потому что я более опытный программист. Если у тебя в API появляется подобная хуйня с важностью порядка запросов, пили транзакционность.
>После /burn ничем не напоминает.
Любое stateful API будет иметь подобные издержки. Можно положить деньги, а потом снять, но не наоборот. Когда я писал про извращенные RPC-протоколы, я имел в виду далеко не это. Вот посмотри тут https://vk.com/dev/upload_files - чтобы загрузить файл нужно вызвать 4 метода, а не один. И попробуй так извратиться, если у тебя REST. Там что-то сложнее одного PUT запроса не будет - а сервер уже должен ебаться с остальным.
>Перечитай свои посты.
Сейчас, подожди, раз ты сказал, то я приготовлю себе большую чашку чая, усядусь поудобнее и буду перечитывать свои посты. LOL.
>Ну если тебе ничего не нужно, зачем ты что-то пишешь?
Передо мной встал вопрос противоречия концепций REST и OOP. Я его тут обсуждаю. Проблемс?
>Пакетное изменение свойств это банальная вещь, и принципиально это от убийства и ранения не отличается - модифицируется стейт.
Ну только пример убийства/ранения ты чето не привел. А обсудить там есть что.
>Потому что я более опытный программист.
LOOOOL
>Если у тебя в API появляется подобная хуйня с важностью порядка запросов, пили транзакционность.
Более опытный программист, ты можешь в separation of concerns? Проблематика данного треда затрагивает взаимодействие REST API, нехуй сюда приплетать лишние сущности.
>Любое stateful API будет иметь подобные издержки.
Ничего себе, неужели стадия принятия.
>посмотри тут https://vk.com/dev/upload_files - чтобы загрузить файл нужно вызвать 4 метода, а не один.
А нет, это еще торг. Т.е. ты хочешь сказать что в RPC невозможно загрузить файл в 1 запрос? Просвещайся, малыш https://www.dropbox.com/developers/documentation/http/documentation#files-upload
>Какой и почему HTTP метод?
REST можно и на одном GET?action=... сделать.
Ты реально лингвист какой-то. То из того, что анон вместо "POST /enemy/1?burn" пишет "POST /enemy/1/burn" делаешь многозначительные выводы, то тебя ебет какой HTTP-метод, как будто это что-то меняет.
серьёзно?
Ебать ты быдло.
Нет, это ты быдло, которое за синтаксисом не видит семантики. Слэш вместо вопросительного знака - все, пиздарики, ваш рест не рест, ведь burn это не ресурс, во как я вас поймал
Долбоёб, где я писал что нужен вопросительный знак? Ты сам это придумал и сам с этим споришь. Я подсказку написал русским языком, прочитай, дятел.
Алло, это я тебе написал, что там нужен вопросителньый знак. burn - это не ресурс, это параметр POST запроса, который меняет соответствующий стейт ресурса. Нет, это не RPC. Да, на RPC так тоже можно. Потому что RPC мощнее и может все, что может REST по определению.
>Передо мной встал вопрос противоречия концепций REST и OOP. Я его тут обсуждаю. Проблемс?
Нет, занимаешься унылой демагогией, потому что всю твою аргументацию разбили, а другой не завезли. Остается, что брать пост на несколько килобайт и найти там противоречия, которые вытекают во основном из того, что ты что-то неправильно понял.
>Т.е. ты хочешь сказать что в RPC невозможно загрузить файл в 1 запрос?
Я написал, что RPC мощнее ровно в том посте, на который ты ссылаешься. Ты почитай его, там многолетний опыт и выжимка того, что ты по жизни редко встретишь.
Суть не в том, что RPC что-то не может, а в том, что RPC слишком мощен. Обрати внимание, что говорят о restful, но не говорят об rpcful. Потому что RPC - это то говно, что получается у любой маньки автоматически. Как есть - вызов процедур издалека. А интернет среда слишком специфическая, чтобы этого было достаточно.
>Нет, это не RPC.
Пока что ни одна макака ИТТ не смогла объяснить почему вызов процедуры является REST и не является RPC.
>Нет, заним... бла-бла-бла
Ваше мнение очень важно для нас.
>ты что-то неправильно понял
Более опытный программист, научись доносить мысли четко, а не мямлить как детсадовец.
В общем ты сам путаешься то у тебя за один запрос файл нельзя отправить, то слишком мощен. Обосрался - так и скажи.
>В общем ты сам путаешься то у тебя за один запрос файл нельзя отправить, то слишком мощен
Ну как я и говорю. Аргументы кончились, пошла демагогия в виде доебок, демонстрирующих собственное непонимание. Я ни разу не писал о том, что RPC нельзя отправить файл одним запросом. Я писал о том, что REST как система правил не позволяет тебе наворотить той хуйни, которую можно наворотить с помощью RPC (inb4 а я и на ресте хуйни наворочу). Если ты не видишь разницы, не знаю, попробуй еще раз перечитать.
А если у тебя цель доказать анону с борд, что он обосрался, так можешь еще написать, что мамку мою ебал.
Любой запрос вызывает процедуру, ты как себе представляешь, HTTP запрос, который ничего не вызывает? Охуенный, наверное, сервер должен быть, сервер, который нихуя не делает.
Ты не тот анон, который возмущался тем, что POST модифицирует стейт сервера?
>Лишний запрос делать? Круто.
Почему ты решил, что он лишний? В этом суть РЕСТ - запрашивай, отвечу.
>POST-запрос создаёт ресурсы. Какой ресурс ты создаешь в данном случае, сжигание? Т.е. одному enemy в качестве вложенных ресурсов может принадлежать 1 сжигание, 1 расчленение, 1 повешение, 1 утопление в кислоте и так далее.
Запрос может создавать ресурсы в какой угодно коллекции, не обязательно вложенные в enemy (это хомячки думают, что обязательно), и/или менять состояние. Он может даже создавать ресурсы вообще на другом сервере, было бы желание. Кстати, клиента это ебсти не должно: он урл объекта получил - и попиздовал по нему.
POST /enemy/1/burn может создавать, например /ashes/1
После подобного запроса все ресурсы, отвечающие за действия исчезают, например, и при попытке доступа к ним сервер отдает 410.
>PUT
Если создается новый ресурс, то только POST
>GET /enemy/1/burn
>GET /enemy/1/dismember
>GET /enemy/1/hang
>GET /enemy/1/aciddrown
Это все не нужно, так как не соответствует предметной области.
Если все эти ресурсы всё еще существуют (а они существуют только, если ни одно из действий до сих пор не выполнено), то на GET в нашей задаче должны отвечать 405.
>Какой и почему HTTP метод?
OPTIONS /enemy/1/collect_ash
Ответит тебе на твой вопрос. Но можно и сразу передавать что-нибудь вида actions: {url: ... , method: ... }
Хуя ты REST-евангелист. Чем это лучше POST /enemy/1?burn ?
Только куча лишнего говна, на которое 405 да 410 отвечай
>Чем это лучше POST /enemy/1?burn ?
Query string обычно используется для уточнения запроса в коллекции. Сортирануть, сделать выборку, вот это всё. Но можно и так, хуле. Тогда семантикой сам наделяй свои УРЛы. Но /enemy/1/burn - это ресурс-действие burn.
>Только куча лишнего говна, на которое 405 да 410 отвечай
Вам дали разнообразный инструмент, а вы только 404, да 200 используете. Как купить ламборгини, чтобы иногда в нем посидеть.
Значит это не укладывается в твой евангелизм, и ты пытаешься изменить уже сам хттп? Приложуха не задеплоена - 404, все верно
404 значит нет пользователя. А как будет "пользователь уволен"? Или "пользователь ушел в туалет"? Какой код выдумаете?
>Но /enemy/1/burn - это ресурс-действие burn.
Хм, но ведь по сути burn это на самом деле создание corpse из enemy.
То есть надо делать POST /corpse {"enemy_url":enemy/1, "method":"burn"}, который повесит на enemy 302.
Ты ответь на вопрос, зачем нужны эти коды
Это служебные коды хттп протокола. Рест евангелисты пытаются натянуть их на бизнес логику
Если предметная область именно такая, то можно и так. Только код будет 301 всё-таки.
Всё уже выдумано до тебя. Используй тот код, который семантически ближе к ситуации, например, "ушел в туалет" - 302, а "уволен" - 410.
Это не ответ на вопрос. Их добавили в протокол чтобы что? Чтобы служить, как в армии что ли?
302 Found, 302 Moved Temporarily
Где тут про туалет? Может все таки не пытаться натянуть сову на глобус?
Чтобы сигнализировать браузеру о статусе страницы
> ты как себе представляешь, HTTP запрос, который ничего не вызывает? Охуенный, наверное, сервер должен быть, сервер, который нихуя не делает.
Есть RESTful URL: https://www.w3.org/WAI/ER/tests/xhtml/testfiles/resources/pdf/dummy.pdf
Он содержит ресурс dummy.pdf.
Ты можешь с ним выполнять любые HTTP-действия и ни одна процедура не вызовется. Круто?
А как к этому ресурсу применить "удалить нечетные абзацы"?
Если тебе не нравятся существующие коды, ты можешь добавить код 433 Resurs syebalsa v tualet. Протокол это позволяет, читай пункт 6.1.1 RFC 2616.
Ты думаешь, что был вот такой HTTP, а потом пришли хипстеры и придумали какой-то там REST, пытаются натянуть что-то там и так далее. А все наоборот. Был продуманный протокол HTTP, придуманный умными мужиками, которые представляли, как интернет должен выглядеть. Все эти практики обозвали умным словом REST. И HTTP по дизайному своему предусматривает
На, почитай
http://www.peej.co.uk/articles/rest.html
https://www.w3.org/TR/2002/WD-webarch-20020830/
https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
Ты в 2002 родился хотя бы?
А потом пришел кровавый энтерпрайз со своим RPC.
>А потом пришел кровавый энтерпрайз со своим RPC.
Маня, в кровавом энтерпрайзе все это было пройдено еще лет 30 назад. Смешно наблюдать, как вы изобретаете wsdl и транзакции
Энтерпрайз способен только создавать убогое распильное bloatware и ничего изобрести не может. Именно поэтому интернет основан на TCP/IP, а не ебучих монстроидальных протоколах телекомовых монстров.
>Почему ты решил, что он лишний?
Потому что без него можно обойтись.
>POST /enemy/1/burn может создавать, например /ashes/1
Может. Но если он что-то и создает, как минимум GET /enemy/1/burn должен быть доступен, т.к. создается именно /enemy/1/burn.
>Если создается новый ресурс, то только POST
Идемпонтентные запросы выполняются с помощью PUT. Сколько ни отправляй запрос на создавание /enemy/1/burn, он может существовать только в одном экземпляре, а значит запросы идемпотентны. PUT.
>Это все не нужно, так как не соответствует предметной области.
Это и есть противоречие. Для предметной не нужно, для REST нужно (есть и другие способы соблюсти РЕСТ конечно).
>OPTIONS /enemy/1/collect_ash
>Ответит тебе на твой вопрос.
На вопрос ответить должен аффтар.
>Где тут про туалет?
302 Found
Location /sortir
Что тебя не устраивает?
ВНЕЗАПНО в REST-е этого нету. О чем и тред.
ЛОООООЛ.
>Ты можешь с ним выполнять любые HTTP-действия и ни одна процедура не вызовется.
Ага, блядь, а файл на мой компьютер святым духом попал, а не в результате http-запроса. Ты наркоман какой-то, то ЗАПРОСЫ не вызывают процедур, то REST у тебя не может менять ресурс, потому что "ну че вы не поправилам играите, я же придумал, что так не может быть, значит так быть не может".
>Потому что без него можно обойтись.
Ну обойдись, если хочешь.
>Может. Но если он что-то и создает, как минимум GET /enemy/1/burn должен быть доступен, т.к. создается именно /enemy/1/burn.
Создается то, что указано в ответе в Location, а не в твоей фантазии.
>Сколько ни отправляй запрос на создавание /enemy/1/burn
Он уже создан давно вместе с enemy. И на него можно послать только один POST запрос.
>для REST нужно
Не нужно.
>На вопрос ответить должен аффтар.
Например OPTIONS /enemy/1/collect_ash вернет
Allowed: POST
>Ну обойдись, если хочешь.
Ну так хули спрашивал чего он лишний.
>Создается то, что указано в ответе в Location, а не в твоей фантазии.
Создается то, что указано в URI, а не твои фантазии.
>>Сколько ни отправляй запрос на создавание /enemy/1/burn
>Он уже создан давно вместе с enemy.
Он никогда не создан потому что это вообще не ресурс.
>И на него можно послать только один POST запрос.
То что ты игнорируешь идемпотентность этого действия, не делает POST уместным. Rule of thumb: POST создает сущности, URI которых неизвестен, PUT создает сущности, URI которых известен. Тут URI только один. Следовательно PUT.
>Не нужно.
Oh wow, да у нас тут аргумент "яскозал".
>>На вопрос ответить должен аффтар.
>Например OPTIONS /enemy/1/collect_ash вернет
>Allowed: POST
Только тут ничего не создается, следовательно POST не катит.
Ты выполнил HTTP-действие GET и получил файл. Ты обратился к RESTful ресурсу. Никакого программного кода за http-сервером даже не запускалось. Беги к врачу, вставляй свечу.
>REST у тебя не может менять ресурс, потому что "ну че вы не поправилам играите, я же придумал, что так не может быть, значит так быть не может".
Не пизди, не говорил я такого.
>Ну так хули спрашивал чего он лишний.
Но ты даже не пояснил как без него можно обойтись, а мне лень у тебя спрашивать дальше.
>Создается то, что указано в URI, а не твои фантазии.
>Он никогда не создан потому что это вообще не ресурс.
Ой всё.
>Oh wow, да у нас тут аргумент "яскозал".
Как и у тебя твой.
>Ой всё.
Еще один Более Опытный Программист. Лол.
>Никакого программного кода за http-сервером даже не запускалось.
А, то есть у нас http-сервер на святом духе работает.
>Oh wow, да у нас тут аргумент "яскозал".
А у тебя аргумент "я нагуглил это пять минут назад на stackoverflow".
Почитай RFC и кончай троллить тупостью. Твой пост полная хуйня. Полнейшая.
При желании можно доебаться до того, что /ashes/1 не является подурлом /enemy/1/burn, но там используется слово usually, и в новом rfc это уточнили. И это все.
Лооол. Макака, ты чего на личности перекатиться решил? Напиши "полнейшая" еще 3 раза, может тогда это будет звучать убедительней.
Твоя аргументация сводится к "ваш ресурс не ресурс, а мой ресурс - ресурс". Ты слишком долго был в ООП. Тебя не вылечить.
Дебил, это не аргументация, а тезис. Разве виноват я что чмони типа тебя не понимают разницы между созданием ресурса и вызовом процедуры.
Имбецил, тезисы, по крайней мере в логике, требуют доказательств. Если у тебя какие-то другие тезисы, то они никому тут нахуй не нужны.
Долбоёб, тезисы подкрепляются аргументацией. Я её привёл дохуя раз.
Вся твоя аргументация сводилась к "смотрите че по ссылке написано", а на поверку оказалось, что написано там то, что говорили тебе. А значит ты либо читать не умеешь, либо ты глупенький упёртый баран. Первое что вряд ли, посты анонов ты всё же как-то умудряешься прочесть.
Неразумные дети, матчасти не знающие, меня спрашивали ссылку какую-нибудь. Я давал. Они там что-то находили что им нравилось, фантазировали под воздействием синдрома утенка. А тем временем ни одна тупая макака, которая тонну говна написала с переходом на личности, не смогла отличить создание ресурса от вызова процедуры.
Я прямо написал, что твои слова противоречат rfc. Если ты этого не понял... впрочем, не похоже, чтобы ты вообще что-то понимал
Маня, тут никто не будет у тебя выпрашивать рассказать какие слова, какое rfc, какое противоречие. Не умеешь излагать - иди нахуй.
Ыыы, так оп еще и сам эту ссылку принес? Лол. А я возмущаюсь, что он rfc не читал. А он в туториале для самых маленьких запутался
>создание ресурса от вызова процедуры.
Процедура - это тоже ресурс, и POST на этот ресурс - это вызов процедуры. И этот вызов не обязательно ломает ограничения REST.
И? По этой ссылке есть разные мнения. Утята умеют только одно воспринимать - которое первым увидели.
checkout is a verb and play are verbs and as you point out at the start it is considered bad practice to use verbs in the URI.
“RESTful URI should refer to a resource that is a thing (noun) instead of referring to an action (verb)”
Also you haven’t mentioned which HTTP method should be called for the controller pattern but if it is GET then you are changing state via a method that should be idempotent.
If it is POST then the controller pattern is RPC rather than REST. A RESTful API would allow the retrieval of the “checkout” resource via
“GET http://api.example.com/cart-management/users/{id}/cart/checkout”
which doesn’t seem to make sense as a request.
It would be better IMO to include a status attribute in the cart resource and update that.
Процедура - часть бизнес-логики. Ресурс - часть бизнес-данных.
Как это не может дойти необучаемым, я не понимаю.
Ресурс может вообще в отрыве от бизнес-логики существовать. Файлы в папочке.
Ресурсом может быть любая сущность, в том числе и процедура.
Как это не может дойти необучаемым, я не понимаю.
А не любитель ли ты MVC, часом?
>И? По этой ссылке есть разные мнения. Утята умеют только одно воспринимать - которое первым увидели.
А, то есть аргументом является мнение некоторого Шона в комментариях к статье, на которую ты сослался.
Не ты с Шоном долбоебы, а все остальные, включая админа того ресурса. Ооок.
На самом деле даже наличие большого и длинного туториала не доказывает ничего о точке зрения, ведь всегда есть вероятность, что автор туториала долбоеб. Но очень забавно, что ты сам принес ссылку на статью, которую прочитал жопой и был уверен, что она подтверждет твои слова, а теперь тебе приходится маневрировать, отыскав коммент анонимуса.
Мм, нет. Ты привел серию утверждений без доказательств:
- Создается то, что указано в URI, а не твои фантазии.
- /enemy/1/burn - не ресурс
- POST создает сущности, URI которых неизвестен, PUT создает сущности, URI которых известен
- ничего не создается, следовательно POST не катит.
Я открыл rfc 2616 (п. 9.5 и 9.6) и rfc 7231 (п. 4.3.3 и 4.3.4) и вижу, что там такого нет. Ссылаться я не могу, потому что я не могу доказать отсутствие.
>Создается то, что указано в URI, а не твои фантазии
Это неправда, POST запрос может как несоздавать что-то и вернуть 200, или создавать и вернуть 20х, при этом адрес ресурса возвращается в поле Location. Все так, как анон выше написал.
>/enemy/1/burn - не ресурс
Если /enemy/1/burn, то что значит буква R в URI? Все, у чего есть URI - ресурс. По, блядь, определнию:
resource
A network data object or service that can be identified by a URI,
as defined in section 3.2. Resources may be available in multiple
representations (e.g. multiple languages, data formats, size, and
resolutions) or vary in other ways.
Перевести нужно, или получится как с той ссылкой на туториал? Ресурс - сетевой объект данных или сервис который может быть идентифицирован с помощью URI. Опа.
>POST создает сущности, URI которых неизвестен, PUT создает сущности, URI которых известен
Интересно посмотреть на то, как ты создашь сущность, URI которой неизвестен.
>REST
>RFC для HTTP
Ну ты лично точно долбоёб.
Ох блядь, а не подскажешь, что нужно почитать, чтобы обосновать следующий высер:
>То что ты игнорируешь идемпотентность этого действия, не делает POST уместным. Rule of thumb: POST создает сущности, URI которых неизвестен, PUT создает сущности, URI которых известен. Тут URI только один. Следовательно PUT.
У меня уже моча кончилась обоссывать тебя.
Утёнок, а у тебя есть собственные мозги чтобы думать, или тебе на всё нужна ссылка на авторитет?
У тебя какая-то каша в голове, анон. Ты путаешь протокол HTTP и архитектурный стиль REST.
У тебя какой-то свой HTTP, отличный от RFC 7231, и какой-то свой REST, отличный от описанного в диссере http://roy.gbiv.com/pubs/dissertation/top.htm . RFC 7231 так же ссылается на этот диссер.
>Утёнок, а у тебя есть собственные мозги чтобы думать, или тебе на всё нужна ссылка на авторитет?
Ой, кто тут у нас? А у нас тут Кулибин, ёпта. RFC - это не авторитет, это, стандарт, т.е. соглашение между разработчиками. Если ты его не придерживаешься, то это твои личные проблемы. Хочешь поменять стандарт? Пиздуй в IETF доказывать свое очень важное мнение и, возможно, тебя услышат.
Т.е. мозгов у тупого утёнка всё-таки нет. Размышлять, аргументировать - не твоё. Тебе нужно указание от барина.
Ну держи, уёба, - https://tools.ietf.org/html/rfc7231#section-4.2.2
Самоделкин, никому не нужно твоё неправильное мнение. Ты в ОП посте спросил что не так с REST, тебе всем двачем показали, что ты не знаком со стандартом, а с RESTом всё в порядке. Если ты хочешь дальше высказывать свое некомпетентное мнение и не пользоваться общепринятым протоколом HTTP, а выдумывать свой, то и не жалуйся, что твой выдуманный РЕСТ не натягивается на твоё ООП.
Чмоня, отучайся говорить за всех. Я тебе дал бумажку от твоего барина с подтверждением моих слов, теперь пожри говна и больше не выёбывайся на взрослых дядь.
>Утёнок, а у тебя есть собственные мозги чтобы думать, или тебе на всё нужна ссылка на авторитет?
Я пытаюсь тебя заставить думать. В посте на который я отвечаю ни слова о REST нет. Там исключительно высер о том, что, оказывается "/enemy/1/burn - не ресурс" и прочие охуительные истории. Если ты пишешь ">REST/>RFC для HTTP", то это очередной случай твоей дислексии, потому что обоссан ты был за чушь по поводу HTTP.
> ни слова о REST нет
А тред называется "REST vs OOP". Следовательно твой высер нерелевантен.
Нет, это твой высер нерелевантен. Ты там доебался до человека, что он использовал не тот HTTP-запрос. Доебался неверно, конечно же (там нужен POST-запрос ответом 201 и полем location, как он и написал), но я уже не помню, чтобы не обосрался хоть в чем-то.
Я еще вчера написал, что по основной теме тебя обоссали еще вчера, и ты трепыхаешься, пытаясь в демагогию. Получается плохо, так как в демагогию ты можешь как и во все остальное.
>моих слов
Про идемпотентность? Никто с тобой про это и не спорил, лол.
>Про идемпотентность? Никто с тобой про это и не спорил, лол.
С тобой действительно про это никто не спорил. И тебе сейчас три человека на это указывают. В посте, на который ты ссылаешься, этого нет. Напоминаю, что ты умственный инвалид, который в айти никогда не добьется успеха, потому что так нельзя.
По семантике, которую заложил в АПИ я, запрос на ресурс /enemy/1/burn должен создавать ресурс в коллекции /ashes/ , а ресурс enemy/1/burn удаляться.
Ты с какого-то хуя начал твердить, что запрос на /enemy/1/burn должен создавать ресурс по этому же УРЛу. В таком случае, бесспорно, должен быть PUT.
Я тебе просто пытался донести ту семантику, которую в этот запрос вложил я. И вдруг ты решил, что я с тобой спорил про идемпотентность, лол. Ну не дебил ли ты сам?
Чмоня пожрала говна с post/put и перешла на личности. Какой же ты говноед.
Еблан, запрос на ресурс в РЕСТ включает в себя verb, когда ты запрос на ресурс обозначаешь одним только URI, это лишний раз показывает что оно не является ресурсом. Это RPC.
Расшифруй слово URI, манька
Ты тупой, чтоле?
POST /enemy/1/burn
verb в URI (burn), метод POST - т.к. операция над этим ресурсом не идемпотентная (создает /ahes/1 и вешает на burn 510), остальные методы на burn возвращают 405.
Хули тебе тут не понятно? Не нравится, что verb в URI, а одноразовый ресурс burn был создан при создании ресурса /enemy/1? Так можешь пройти нахуй, ни стиль REST, ни протокол HTTP не накладывают ограничений на это. И при этом АПИ вполне соответствует предметной области.
>510
410 конечно же
>Ты тупой, чтоле?
С подключением
Ну так могёшь и сам нахуй пойти, коли не понимаешь разницы между REST и RPC.
Манька, расскажи расшифруй разницу между REST и RPC.
Ну так ты покажи, где конкретно ты в этом примере увидел RPC.
Тыщу раз объяснил в треде. Начиная с ОП-поста. Ни один из тех, кто не согласен, не может объяснить в чем разница между REST и RPC и называет РЕСТом всё на свете, даже небо, даже Аллаха на основании того, что в URI есть слово resource.
Единстенный кто попытался объяснить разницу, сказал что разницы не знает нет .
Остальные даже не пробовали ответить.
Так тебя смущает наличие глагола в URI? В REST на это ограничения нет, что я тебе тыщу раз в этом треде говорил, но ты так и не привел ни одной цитаты ни из диссера, ни из какого-нибудь rfc, подтверждающего твою правоту. При этом ты упорно продолжаешь твердить своё, ссылаясь на какого-то рандомного хуя из интернетов. И этот хуй всего-лишь оставил комментарий к статье, в которой даже сам автор допускает глаголы в URI.
Меня смущает что ни один долбоёб включая тебя не понимает разницу между REST и RPC. Я блядь открытым текстом это пишу который раз.
Я понимаю разницу. А вот ты - нет.
Чё ещё спизданешь.
Чё ещё спизданешь.
Эта макака сломалась, несите следующую.
Мало обоссали? Вот тебе еще урины, даунёнок:
https://ru.wikipedia.org/wiki/REST#4._%D0%95%D0%B4%D0%B8%D0%BD%D0%BE%D0%BE%D0%B1%D1%80%D0%B0%D0%B7%D0%B8%D0%B5_%D0%B8%D0%BD%D1%82%D0%B5%D1%80%D1%84%D0%B5%D0%B9%D1%81%D0%B0
И это самое важное, что есть в REST и нет в RPC.
Когда сделаешь тот же пример с burn/dismember/kill на RPC и сможешь объяснить в чем разница с твоим "REST", тогда поговорим.
А пока, даунёнок, не плюйся, а держи урину в своём рту.
Принимай урину дальше, дебил.
Например, JSON-RPC (транспортный протокол не важен)
Запрос: {"id": 1, "method": "kill", "params": {"enemy": 1}}
Ответ: {"id":1, "result": "killed"}
И подобные запрос-ответы.
Как видишь, никаких ресурсов не создается (а их и нет в терминологии рпц, лол), АПИ известен двум сторонам заранее, всё это неюниформно, т.е. у каждого сервиса своё. И все это в отличие от REST, где есть одна входная точка в сервис, а дальше по ссылочкам, ходишь по ресурсам, которые динамичны, юниформны, самоописуемы, и предоставляют новые ссылки. Красота.
За остальной порцией урины снова пройди в википедию, в rfc и в диссер филдинга.
Только такой долбоёб как ты мог написать "запросы" без URL-ов.
Найди хоть одно слово URL в спецификации JSON-RPC.
Как это поможет воспользоваться сетевым API у которого нет ни одного URL.
Например, через сокеты
У нас HTTP API без сокетов.
Псссссь
Тупорылая макака ещё раз подтвердила свой уровень.
Если тебе нужен урл для жсон-рпц, тогда вот: /
И попробуй кукарекни, что это не урл, дебил.
Oh wow, что это тут у нас? Да это же мать его РЕСУРС.
Осталось выяснить, глагол это или существительное
Если это ресурс, какая разница. Ресурс - значит это REST.
Ты думаешь RES в слове REST от слова ресурс что ли?
>Ресурс - значит это REST.
Пиздуй читать про REST. И пока от зубов не будут отскакивать все ограничения, накладываемые на сервис, не смей тут даже кукарекать.
Вот же ты еблан с памятью рыбки. Выше по треду выяснили что R - ресурс в URI/URL.
Долбоёб, это тебе надо читать, потому что это ты выше доказывал что URI=РЕСУРС с точки зрения РЕСТ.
Мудак чтоле? URI - это ресурс (адрес, имя ресурса, как хочешь называй) в HTTP. REST тут каким боком вылез?
Ну и что дальше? Из того, что точка входа в JSON-RPC - это ресурс по адресу / не следует ничего из того, что ты пытаешься доказать. Тут никто не утверждал, что у RPC нельзя HTTP использовать как транспорт
Выше по треду маня доказывала что `/enemy/1/burn` - это РЕСТ, поскольку наличие ресурса соблюдено, поскольку есть URI, и похуй что обращение к процедуре.
Ну так и здесь есть URI, я жду когда маньки смогут объяснить в чем же сакральное различие. Такая же неконсистентная неюниформная параша с протоколом че когда вызывать можно.
Ну ты тупооой. Ресурс не может быть REST. Ресурс может быть RESTful, если он соблюдает ограничения REST. Я тебе весь тред об этом твержу, но ты, еблан, похоже жопой читаешь.
И ты так и не показал какое именно ограничение REST нарушает ресурс-контроллер (процедура, функция, как хочешь назови), а всё маняврируешь со своим ебаным рпц.
>Такая же неконсистентная неюниформная параша
Докажи
>Выше по треду маня доказывала что `/enemy/1/burn` - это РЕСТ
Это уже наверное десятый раз в треде, когда ты доказываешь, что ты не умеешь читать. Был диалог
"""
>>Сколько ни отправляй запрос на создавание /enemy/1/burn
>Он уже создан давно вместе с enemy.
Он никогда не создан потому что это вообще не ресурс.
"""
В котором тебя обоссали, так как - /enemy/1/burn - это ресурс, по определнию. Даже твоя мамка может быть ресурсом, если выдать есть URI.
Дальше ты врубаешь логику, мол, а "/" тоже ресурс, а ЗНАЧИТ У ВАС ПРОТИВОРЕЧИЕ. Только вот противоречия нет. Оно в твоей тупой башке. Из того, что твоя мамка - ресурс, не следует, что она часть restful API. А вот если окажется, что она подчиняется определенным правилам, то тогда да.
>/enemy/1/burn
Т.е. это ресурс, но не restful API?
>>Такая же неконсистентная неюниформная параша
>Докажи
Придумал для enemy неюниформный экшен burn (и кучу других) просто потому, что захотел. У других сущностей его нет. Правил по которым такие экшены создаются тоже нет, кроме желания твоей левой пятки. Хуй положил на консистентность.
После первого вызова `POST ../burn` все последующие будут возвращать ошибку - надо соблюдать протокол что зачем вызывать.
>И ты так и не показал какое именно ограничение REST нарушает ресурс-контроллер (процедура, функция, как хочешь назови), а всё маняврируешь со своим ебаным рпц.
Я всё показал тысячу раз, если у тебя мозгов не хватает стол от стула отличить, кто тебе доктор.
>неюниформный
Этот ресурс запрашивается методом POST. А значит юниформный.
>У других сущностей его нет.
Это ограничение REST?
>Правил по которым такие экшены создаются тоже нет
Это ограничение REST?
>Хуй положил на консистентность
А вот тут подробнее давай. Где же тут неконсистентность-то зарылась?
>После первого вызова `POST ../burn` все последующие будут возвращать ошибку
Вот этого я от тебя и ждал, лол. Ну не долбоёб же ты? Вот тебе пример попроще: после вызова, скажем, DELETE /collection, POST /collection {newitem: ...} будет возвращать ошибку. Тоже не REST?
>надо соблюдать протокол что зачем вызывать.
Не надо никаких протоколов. Ресурс сам тебе расскажет что с ним можно делать, а что нельзя.
>Я всё показал тысячу раз, если у тебя мозгов не хватает стол от стула отличить, кто тебе доктор.
Ты выдумал свой REST
>>неюниформный
>Этот ресурс запрашивается методом POST. А значит юниформный.
Лол. В огороде бузина, значит в Киеве дядька.
>>У других сущностей его нет.
>Это ограничение REST?
Это неюниформность.
>>Правил по которым такие экшены создаются тоже нет
>Это ограничение REST?
Это неюниформность.
>>Хуй положил на консистентность
>А вот тут подробнее давай. Где же тут неконсистентность-то зарылась?
Повсеместно.
>>После первого вызова `POST ../burn` все последующие будут возвращать ошибку
>Вот этого я от тебя и ждал, лол. Ну не долбоёб же ты? Вот тебе пример попроще: после вызова, скажем, DELETE /collection, POST /collection {newitem: ...} будет возвращать ошибку. Тоже не REST?
Это REST. И это отсутствие ресурса, который был удален. Только ты не DELETE используешь и не удаляешь.
>>надо соблюдать протокол что зачем вызывать.
>Не надо никаких протоколов. Ресурс сам тебе расскажет что с ним можно делать, а что нельзя.
В том числе, что можно вызвать kill, затем burn, но не наоборот? И что kill и burn можно вызывать по одному разу только?
У тебя свое определение юниформности. Проблема в том, что это не политические споры, определения у всех одни и те же.
А именно такое:
In order to obtain a uniform interface, multiple architectural constraints are needed to guide the behavior of components. REST is defined by four interface constraints: identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state.
Дальше на SO можно найти расшифровку:
Identification of resources - You use the URI (IRI) standard to identify a resource. In this case a resource is a web document.
Manipulation of resources through these representations - You use the HTTP standard to describe communication. So for example GET means that you want to retrieve data about the URI identified resource. You can describe an operation with a HTTP method and an URI.
Self-descriptive messages - You use standard MIME types and (standard) RDF vocabs to make messages self-descriptive. So the client can find the data by checking the semantics, and it don't have to know the application specific data structure the service uses.
Hypermedia as the engine of application state (A.K.A. HATEOAS) - You use hyperlinks and possibly URI templates to decouple the client from the application specific URI structure. You can annotate these hyperlinks with semantics e.g. IANA link relations, so the client will understand what they mean.
И чекаем
You use the URI (IRI) standard to identify a resource - это есть
You use the HTTP standard to describe communication - это есть
You use standard MIME types and (standard) RDF vocabs to make messages self-descriptive - это не упоминалось, но довольно очевидно
You use hyperlinks and possibly URI templates to decouple the client from the application specific URI structure - это тоже есть. Он возвращает адрес трупа в поле Location
>В том числе, что можно вызвать kill, затем burn, но не наоборот? И что kill и burn можно вызывать по одному разу только?
Вызвав kill ресурс тебе скажет, что burn вызывать уже нельзя. Вызвав burn - аналогично.
>Вызвав kill ресурс тебе скажет, что burn вызывать уже нельзя. Вызвав burn - аналогично.
>надо соблюдать протокол что зачем вызывать.
>So for example GET means that you want to retrieve data about the URI identified resource.
Делаешь POST /enemy/1/kill чтобы создать ресурс /enemy/1/kill. Получаешь что? Что твоей левой пятке захотелось, а создать такой ресурс вообще невозможно.
>You can describe an operation with a HTTP method and an URI.
Для /enemy/1/kill HTTP method вообще неважен, т.к. у процедуры всего одна операция - вызов.
>Делаешь POST /enemy/1/kill чтобы создать ресурс
Это очередной пример документации, прочтенной твоей жопой.
POST /enemy/1/kill не обязан создавать ресурс /enemy/1/kill, он может создать ресурс по любому адресу, а может вообще ничего не создавать, при в этих двух случаях будут разные коды возврата, более того, для создания ресурса по тому же адресу следует выбрать PUT.
В данном случае он создает ресурс по адресу типа /corpse/1 или как там (лень вверх смотреть), который передает тебе в поле Location для дальнейшей работы. Создавать ресурс по другому адресу POST с помощью прямо разрешено.
>Для /enemy/1/kill HTTP method вообще неважен, т.к. у процедуры всего одна операция - вызов.
Для restfulness важно, GET не меняет стейт ресурса, PUT меняет идемпотентно, POST неидемпотентно.
>Лол. В огороде бузина, значит в Киеве дядька.
>неюниформность
Значение униформности в REST знаешь?
Изучай, имбецил:
https://en.wikipedia.org/wiki/Representational_state_transfer#Uniform_interface
>Повсеместно
Слив защитан.
>Только ты не DELETE используешь и не удаляешь.
Лол, браузеры тоже в DELETE/PUT/PATCH не умеет до сих пор (js не в счёт), однако всё это делают при помощи POST. Еще скажи тут не REST. Универсальный метод POST годится для всего, чего пожелаешь, автор REST тут тебе поясняет, что он имел ввиду под REST:
https://roy.gbiv.com/untangled/2009/it-is-okay-to-use-post
>В том числе, что можно вызвать kill, затем burn, но не наоборот?
А кого ебёт последовательность? Есть список ресурсов, выбирай любой, шли запрос. И не факт, что эти ресурсы всё ещё будут существовать когда ты сделаешь свой первый запрос на один из них: например, другой пользователь уже сделал burn, пока ты сиськи мял.
>И что kill и burn можно вызывать по одному разу только?
А кого это ебёт, сколько раз можно? Ресурс есть - вернется представление, ресурса нет - вернется ошибка
>POST /enemy/1/kill не обязан создавать
Долбоёб, где твоя жопа увидела увидела в моём сообщении слово ОБЯЗАН.
>Для restfulness важно, GET не меняет стейт ресурса, PUT меняет идемпотентно, POST неидемпотентно.
Так НЕ ОБЯЗАН же. Ты только что отказался поддерживать конвенцию. а может вообще ничего не создавать
>Долбоёб, где твоя жопа увидела увидела в моём сообщении слово ОБЯЗАН.
Мы обсуждаем вписывается ли API анона в REST. Ты говоришь, что ты делаешь POST чтобы создать ресурс, а эта скотина возвращает тебе moved permanently и адрес праха трупа (мол, опоздал, чувак) и называешь это "твоей левой пятке захотелось".
Так вот, это желание левой пятки полностью вписывается в REST.
>Так НЕ ОБЯЗАН же. Ты только что отказался поддерживать конвенцию. а может вообще ничего не создавать
Какую конвенцию, твой маня-рест, который ты сам придумал? Тебя уже автор REST обоссывает, лалка.
>Значение униформности в REST знаешь?
Выше пояснил проблемы.
>Слив защитан.
Анус себе защитай, пёс.
>браузеры тоже в DELETE/PUT/PATCH не умеет до сих пор
Ты чё, ебанутый?
>однако всё это делают при помощи POST
Костыль ныне не нужный.
>А кого ебёт последовательность?
Клиента.
> И не факт, что эти ресурсы всё ещё будут существовать когда ты сделаешь свой первый запрос на один из них: например, другой пользователь уже сделал burn
У тупых макак удаление ресурса не через rest-action delete, а через вызов процедуры burn.
>А кого это ебёт, сколько раз можно? Ресурс есть - вернется представление, ресурса нет - вернется ошибка
Клиента. Если ресурса нет, то и вопроса нет, только как выяснили выше ты и удаляешь ресурсы как макака.
Конвенцию того, что делая запрос POST /enemy/1/burn, ты намереваешься создать ресурс с URI /enemy/1/burn, над которым можно делать стандартные http операции.
Так-то ты можешь дилдаком себя в срачельник оттарабанить и кукарекать что это не нарушает рест, ведь и правда не нарушает.
>Конвенцию того, что делая запрос POST /enemy/1/burn, ты намереваешься создать ресурс с URI /enemy/1/burn, над которым можно делать стандартные http операции.
Лалка, такой конвенции НЕТ. Конвенциональный метод для создания ресурса ПО ТОМУ ЖЕ АДРЕСУ - PUT.
POST НЕ используется для этого.
Какой же ты тупой.
>Этот ресурс запрашивается методом POST
>POST НЕ используется для этого.
Какой же ты тупой.
Где в процитированном тобой сообщении слово "создается", в твоем маня-мирке опять? Опять жопой читаешь? Опять хочешь обоссывания?
>Выше пояснил проблемы.
Твои пояснения никак не соотносятся с определением униформности
>Анус себе защитай, пёс.
Мемасики пошли у мартышки, отлично. А за консистентность так и не пояснил.
>Ты чё, ебанутый?
Нет ты.
>Костыль ныне не нужный.
Ты скозал?
>rest-action delete
Чмоня, ты до сих пор путаешь REST и HTTP, хотя по этому поводу тебя уже обоссали и не раз.
>Клиента.
В представленном АПИ клиенту похуй. Ему дали урл, а что там по урлу он узнает только сходив по нему - это и есть суть HTTP протокола, дебил.
Правильно, макакам нахуй не нужны конвенции, макака будет использовать POST для .... сама не знает для чего, на то она и макака.
Дай ссылку на эту конвенцию, про которую ты все пиздишь
На конвенцию из манямирка ссылаться невозможно.
>The following table shows how HTTP methods are typically used in a RESTful API:
>there is no "official" standard for RESTful Web APIs
>Many developers also describe their APIs as being RESTful, even though these APIs actually don't fulfill all of the architectural constraints described above (especially the uniform interface constraint).
Этого на скрин, конечно же, не влезло по идеологическим причинам.
Это скриншот какой-то таблички, а не конвенция
Не думаю. Он скорее всего очень хуево знает английский и обладает богатой фантазией.
Не замечая при этом, что, например, в табличке GET повторяется два раза, а про PUT не сказано, что он может создавать ресурс. То есть это табличка с примерами типичных действий, заведомо неполная.
Меня каждый раз порывает написать "и че, ссылаешься на какого-то блогера, а может он долбоеб", но каждый раз оказывается, что написано там в общем-то верно, а опушка очередной раз прочитал жопой.
Да, совершенно верно. Есть пидарасы типа тебя, которые делают левую хуйню, и называют её РЕСТ, хотя она не отвечает uniform interface.
Именно об этом статья Филдинга, на которую стоит ссылка в Вики над твоей цитатой, в которой он кроет хуями пидарасов таких как ты:
http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
>I am getting frustrated by the number of people calling any HTTP-based interface a REST API. Today’s example is the SocialSite REST API. That is RPC. It screams RPC. There is so much coupling on display that it should be given an X rating.
>A REST API should not be dependent on any single communication protocol, though its successful mapping to a given protocol may be dependent on the availability of metadata, choice of methods, etc. In general, any protocol element that uses a URI for identification must allow any URI scheme to be used for the sake of that identification. [Failure here implies that identification is not separated from interaction.]
/enemy/1/kill - это identification
/enemy/1/kill - это interaction
FAIL
GET там зачем-то для двух типов ресурсов запилили, как будто коллекция чем-то принципиально отличается от элемента коллекции.
Опять жопой читаешь. Я привел эту цитату, т.к. ты выдумал какую-то конвенцию, которой нет и в помине.
>/enemy/1/kill - это interaction
Это точно такой же identification, единый и не делимый. Kill - это подресурс, а Interaction в данном случае POST. Обращение к этим ресурсам возвращают их полные представления и нет никакого протокола взаимодействия поверх HTTP.
Филдинг говорит совершенно о другом: нехуй запиливать протоколы, т.е. делать что-то, что необходимо знать помимо представления ресурса. И этим занимаешься именно ты. У тебя, блять, rest-method delete, put-хуют, именно ты считаешь HTTP методы неотъемлемой частью REST, ты выдумал какую-то последовательность действий для моего примера и требования знания клиентом об одноразовости ресурсов.
В моем примере клиенту достаточно знать только то, что есть в представлении и это есть RESTful. О чем я тебе твержу тут уже полтреда, но ты упоролся в рпц.
Нахуя ебаться с REST'ом, собачась с HTTP-кодами, если можно просто использовать RPC?
И мощнейшая порция урины от самого Филдинга (из комментариев к статье):
>Resources are not storage items (or, at least, they aren’t always equivalent to some storage item on the back-end). The same resource state can be overlayed by multiple resources, just as an XML document can be represented as a sequence of bytes or a tree of individually addressable nodes. Likewise, a single resource can be the equivalent of a database stored procedure, with the power to abstract state changes over any number of storage items.
>You use hyperlinks and possibly URI templates to decouple the client from the application specific URI structure
/enemy/1/kill - это как раз application specific URI structure.
Если правила в твоей игре завтра поменяются так, что убивать врагов больше нельзя, этот URI станет неюзабельным. А вот enemies никуда не денутся.
Ну не тебе толковать Филдинга. Он написал что написал.
Можешь найти API, который он конкретно ругает в своей статье, там такая же параша, как /enemy/1/kill
>>/enemy/1/kill - это interaction
>Это точно такой же identification, единый и не делимый. Kill - это подресурс, а Interaction в данном случае POST.
Включаем логику. У чего угодно в вебе есть URI, по твоей логике - identification. Для доступу к чему угодно через HTTP надо использовать HTTP-метод: GET, POST и т.д. - любой, по твоей логике - Interaction. Значит, ни один HTTP запрос не нарушает этого требования.
Или Филдинг с требованием обосрался, или ты с понимаем REST.
О том, что возвращает запрос `POST /enemy/1/kill` в разное время было сказано:
>POST запрос может как несоздавать что-то и вернуть 200, или создавать и вернуть 20х, при этом адрес ресурса возвращается в поле Location
>там нужен POST-запрос ответом 201 и полем location, как он и написал
>Обращение к этим ресурсам возвращают их полные представления
Кое-кто тут запизделся.
>А вот enemies никуда не денутся.
Ты скозал?
Ты хочешь, чтобы глаголы куда-то девались, а существительные нет, но это исключительно твое желание, чтобы пропихнуть свою демагогию. Деться может что угодно, важно то, как сообщить об этом клиенту. В случае RPC у тебя нет универсального способа, а в случае REST ты получаешь список контроллеров с помощью GET /enemy/1/, в которой будет список гиперссылок на методы enemy. Это и есть то, о чем говорит английский текст и выше писалось.
>Ну не тебе толковать Филдинга. Он написал что написал.
В случае вашего общения ты должен смотреть в рот этому толкователю, потому что у вас очень разный уровень. Ты не самый умный человек на свете, прикинь. Ты даже на этой доске не в топе 10. Но пока ты будешь таким высокомерным долбоебом, у тебя очень хуевые перспективы по жизни.
Даже я со своим опытом узнал от него много нового, потому что видно, что анон тему REST просекает очень хорошо. А тебе остается деградировать и нюхать свой пердеж от ощущения своей охуенности.
>Или Филдинг с требованием обосрался, или ты с понимаем REST.
Или обосрался ты.
>Можешь найти API, который он конкретно ругает в своей статье, там такая же параша, как /enemy/1/kill
Может ты конкретный пример приведешь или ты думаешь, что я это API не найду для обоссывания?
Заголовок говорит просто: REST APIs must be hypertext-driven. Перевести? Его претензия в том, что там нет гипертекста.
Дальше в комментах он расшифровывает
The OpenSocial RESTful protocol is not RESTful. It could be made so with some relatively small changes, but right now it is just wrapping RPC results in common Web media types.
A truly RESTful API looks like hypertext. Every addressable unit of information carries an address, either explicitly (e.g., link and id attributes) or implicitly (e.g., derived from the media type definition and representation structure). Query results are represented by a list of links with summary information, not by arrays of object representations (query is not a substitute for identification of resources). Resource representations are self-descriptive: the client does not need to know if a resource is OpenSocialist because it is just acting on the representations received.
Think of it in terms of the Web. How many Web browsers are aware of the distinction between an online-banking resource and a Wiki resource? None of them. They don’t need to be aware of the resource types. What they need to be aware of is the potential state transitions — the links and forms — and what semantics/actions are implied by traversing those links. A browser represents them as distinct UI controls so that a user can see potential transitions and anticipate the effect of chosen actions. A spider can follow them to the extent that the relationships are known to be safe. Typed relations, specific media types, and action-specific elements provide the guidance needed for automated agents.
То есть его претензии к результатам выдачи, что там выдаются поля, специфичный для приложения, типа id, а не гиперссылки.
>Кое-кто тут запизделся.
Или ты опять обосрался с пониманием. Ты обращай внимания на модельные глаголы, как "может", "нужен", на время глагола и прочие вещи. И тебе откроются знания, которые тебе пытаются донести, а не собственные фантазии.
Не я скозал, а это очевидно. Да ты и против ничего не высказал по сути.
Правда, в самом слове enemy есть логика противоборства, поэтому лучше заменить его на player. Заодно это избавит от ситуации, когда каждый участник не может получить enemy с собственным id (ведь сам себе врагом быть не можешь).
>В случае вашего общения ты должен смотреть в рот этому толкователю, потому что у вас очень разный уровень
Твой километровый высер дальше читать нет сил от смеха.
>Не я скозал, а это очевидно.
Нет, ты сказал. Потому что очевидно другое: твои слова о версионности можно применить к любому REST-апи. "А что, если ресурс пропадет, ошибка что ли будет". Да, будет.
>Да ты и против ничего не высказал по сути.
Да как-то похуй. Нормальный человек спорит прежде всего с собой. Ты же споришь с другими в расчете на то, что твоя демагогия прокатит. А она не прокатывает, так как собеседники у тебя как раз спорят не с тобой - они ищут истину.
>Правда, в самом слове enemy есть логика противоборства, поэтому лучше заменить его на player. Заодно это избавит от ситуации, когда каждый участник не может получить enemy с собственным id (ведь сам себе врагом быть не можешь).
И вот ты вернулся в свою уютную гуманитарную хуйню про игоры. Это совсем не интересно, какое там слово. Суть твоей претензии в том, что в REST не может быть глаголов, и тебя обоссали уже с цитатой автора этого термина.
>Твой километровый высер дальше читать нет сил от смеха.
От батхерта у тебя нет сил читать, у тебя всегда бомбит, когда я говорю, что ты не самый умный здесь.
> Потому что очевидно другое: твои слова о версионности можно применить к любому REST-апи
Мои слова были о application specific URI structure, а не версионности. Иди дальше истину ищи, искатель.
Я уже все нашел (лично я не понимал важность гиперссылок в rest, анон обратил внимания и теперь я тоже вижу что в тех rest api, везде ссылки), второй день захожу в тред только пописюнькать на тебя. О "application specific URI structure" ты тоже нихуя не понял, как водится.
А, мочехлёб, это ты.
>Включаем логику. У чего угодно в вебе есть URI, по твоей логике - identification. Для доступу к чему угодно через HTTP надо использовать HTTP-метод: GET, POST и т.д. - любой, по твоей логике - Interaction. Значит, ни один HTTP запрос не нарушает этого требования.
Нет. Требование нарушается, если запрос, и/или ответ нарушают протокол HTTP. Например действие - часть URI, на нарушение чего ты и ссылаешься. Например POST /enemy/1/update вместо заложенной в HTTP протокол PUT /enemy/1 . Но с /enemy/1/kill совершенно другая ситуация - это ресурс-контроллер, который делает нечто большее, чем атомарный PUT /enemy/1 и это нечто должно быть атомарным. Кроме того, важно помнить, этот ресурс получен из представления другого ресурса, и возвращает новое представление. А у /enemy/2 может вообще не быть подресурса kill, потому, что это самолёт и у него будет, например, /enemy/2/destroy.
Да, если POST /enemy/1/kill сводится к PUT /enemy/1 {status: killed}, и, самое главное, был бы задокументирован где-то вне представления, а значит URI /enemy/1/kill не может не существовать, то вопросов нет, то это типичный RPC.
>Кое-кто тут запизделся.
А любые запросы GET, POST, итд возвращают представления ресурсов, в соответствии с протоколом HTTP, разве не очевидно? Если представление ресурса - это факт создания ресурса, то тебе это и возвращается.
>Но с /enemy/1/kill совершенно другая ситуация
С этого места пошло твоё личное мнение, оно не выглядит обоснованным.
>если POST /enemy/1/kill сводится к PUT /enemy/1 {status: killed}
Что значит "сводится"?
>а значит URI /enemy/1/kill не может не существовать
Из чего значит? Абзац без смысла.
>представление ресурса - это факт создания ресурса
Как может факт создания быть ресурсом? Ресурсом может быть информация о создании, к который ты сможешь раз за разом обращаться. Может быть сущность, к которой ты опять же можешь обращаться. У ФАКТА СОЗДАНИЯ может быть URI вообще?
Если метод POST означает создание ресурса, а ресурсом является факт создания ресурса, получается запрос POST /enemy/1/kill создает факт создания ресурса. И с этим ресурсом нельзя сделать ничего. Странный "ресурс".
>>представление ресурса - это факт создания ресурса
>Как может факт создания быть ресурсом?
Не ресурсом, а представлением ресурса. Смотрю в книгу - вижу фигу.
§ 5.2.1.1 Resources and Resource Identifiers
The key abstraction of information in REST is a resource. Any information that can be named can be a resource: a document or image, a temporal service (e.g. “today’s weather in Los Angeles”), a collection of other resources, a non-virtual object (e.g. a person), and so on. In other words, any concept that might be the target of an author’s hypertext reference must fit within the definition of a resource. A resource is a conceptual mapping to a set of entities, not the entity that corresponds to the mapping at any particular point in time... (There's more, click the link to read on).
Really a resource can be abstract concept that that is identifiable by a URI and can be represented in transmittable data.
§ 5.2.1.2 Representations
REST components perform actions on a resource by using a representation to capture the current or intended state of that resource and transferring that representation between components. A representation is a sequence of bytes, plus representation metadata to describe those bytes.
То есть является ли сообщаемый нами факт создания ресурса последовательностью байт с http-заголовком? Да, является.
Такой сложный абстрактный тремин нужен, потому что сказать "файл", "документ" и т. д. слишком конкретно.
Последовательность байтов - это представление ресурса. Ну а ресурс-то какой? Что ты создаешь делая этот ПОСТ? Создаешь факт создания?
>С этого места пошло твоё личное мнение, оно не выглядит обоснованным.
Какое тебе, нахуй, обоснование? С этого места я объяснил тебе как устроен ресурсне надо было, что у него есть URI, что URI и взаимодействие с ним не нарушает HTTP, и он соответствует REST но ты опять нихуя не понял.
>Что значит "сводится"?
Это значит, что нет разницы между POST /enemy/1/kill и PUT /enemy/1 {status: killed}
>Из чего значит? Абзац без смысла.
Из внешней документации.
>Как может факт создания быть ресурсом?
Раз уж так придираешься к словам, то все как ты сказал. Кроме одного. Информация о создании - это представление ресурса, а не сам ресурс.
>Ну а ресурс-то какой?
Какая нахуй разница? У тебя есть представление ресурса, вот из него и получай всю информацию о ресурсе, об этом тебе говорит REST.
>Ну а ресурс-то какой
"any concept that might be the target of an author’s hypertext reference must fit within the definition of a resource"
Можно написать <a href="/enemy/1/kill">убить супостата</a>? Можно. Значит это ресурс.
>Что ты создаешь делая этот ПОСТ
Не помню, что там было /corpse/1/. Но пост не всегда означает создание ресурса. Как и пут. Хотя в данном случае это так.
>Можно написать <a href="/enemy/1/kill">убить супостата</a>? Можно. Значит это ресурс.
Естественно html не поддерживает POST запросы таким образом, но это уже ограничение HTML
>>Ну а ресурс-то какой?
>Какая нахуй разница?
Тащем-та вся суть макак.
Это называется способность к абстрагированию. В чем лично твоя не макачность заключается? Дохуя проектов поднял?
Дурачок, чтоле? Клиенту вернулось представление ресурса. Ну как его может ебсти, что за этим представлением скрываются 10 файлов на диске и 100 рекородов в БД? Если клиента ебёт и он должен знать, что там именно 10 файлов, а не 10 ответов с 10 сторонних серверов, то у сервиса неправильный АПИ.
Это называется способность лепить говно.
>В чем лично твоя не макачность заключается? Дохуя проектов поднял?
А это называется переход на личности. Типичный приём макаки.
>Это называется способность лепить говно.
Нет. Ты просто не программист и тебе не понять.
>А это называется переход на личности. Типичный приём макаки.
Так это ты написал "Тащем-та вся суть макак" и перевел все в эту плоскость. А личность у тебя лузера, прямо скажем.
Мочехлёб pls.
Дурачок, клиенту надо понимать ЧТО именно ему вернулось, чтобы понимать что с этой сущностью делать.
Заклинание написал, а ответа ушел. В чем лично твоя не макачность заключается?
Пока ты показал только непонимание русского и английского языка, тупизну и постоянное переспрашивание одного и того же. Может я что-то не знаю, расскажи о себе.
Ресурс ему не может вернуться, только представление. Сам ресурс клиента не ебет.
Где ты в моем предыдущем сообщении увидел слово ресурс?
Ай лолд, сейчас всё брошу и тупой макаке о себе рассказывать буду.
Что бросишь, ты круглые сутки на дваче сидишь
Ему вернулось представление ресурса. Это все, что ему надо знать. В этом представлении есть нужные URI, Content-Type, тело сообщения и вся другая необходимая информация.
С таким подходом ты допиздишься до того, что даже в невинном RESTful GET /person/op , возвращающем {age:13, height: "150cm", mass: "260kg", color: green } нихуя не понятно, что именно ему вернулось, если он не знает джсона и ангельского, лол.
Какого блядь ресурса? Ты запросил огурец, а тебе вернулся слон.
Макака, не проецируй.
>С таким подходом ты допиздишься до того, что даже в невинном RESTful GET /person/op , возвращающем {age:13, height: "150cm", mass: "260kg", color: green } нихуя не понятно, что именно ему вернулось, если он не знает джсона и ангельского, лол.
Конечно нет, представление-то не полное, не указано, что оп тупой уебок
>Ты запросил огурец, а тебе вернулся слон.
Очевидно, что в этом случае слон является представлением ресурса по URI огурец.
Осталось такой логичный АПИ приправить спагетти-кодом и блюдо готово.
Сам придумал - сам обосрал
>такой логичный АПИ
Ты его предложил.
>приправить спагетти-кодом
Ты его и готовь.
Ну вообще теперь понятно, как ты пишешь программы и что у тебя вместо АПИ.
Вряд ли он вообще что-то пишет
>Ты его предложил.
Охуительные истории.
>Ты запросил огурец, а тебе вернулся слон
Это в точности запросил kill, получил corpse.
Да, все плохо, нет никакого rest, ты подебил.
Всё же, таки, ты жопой чтец. Запросил kill, получил представление ресурса kill: ответ 201 Created и URI на corpse.
Представление corpse ты получишь, если пройдешь по предоставленному УРЛу.
Тебе английским языком всё написано, ты вместо чётких формулировок выдумываешь свои толкования, а жопой чтец почему-то я. Как так?
Ты похерил decoupling of identification and interaction. Ты HTTP-specific ответ (location header) называешь полным представлением ресурса.
Если собственными фантазиями ("на самом деле Филдинг имел ввиду") конкретные формулировки, если ты кладёшь хуй на консистентность интерфейса АПИ, разве могу я это запретить тебе.
Ну так предложи фикс этой ситуации, лол
Ой не пизди. У тебя одни вскукареки, жопочтение Филдинга и вырванные из контекста фразы.
На все твои ответы есть ответы выше по треду.
>консистентность интерфейса АПИ
Консистентность интерфейса? Ты сам понял что сказал, мудак тупой? REST требует униформности, но ты, настолько имбецил, что путаешь эти два разных понятия.
Нет у тебя жопочтение. Основанное на толковании мыслей Филдинга лол.
Консистетность это в принципе требование любого хорошего дизайна, долбоёб ты тупорылый.
Ты из контекста вырываешь его фразы, идиот. Ты русский-то хуёво понимаешь, а уж ангельский так вообще нихуя. Увидел фразочку со знакомыми словами и давай притягивать её за уши к своему высеру.
>Консистетность это в принципе требование любого хорошего дизайна
Этой фразой ты лишь подтвердил свой долбоебизм и непонимание термина.
Требование консистентности относится к данным, а не к интерфейсам, ебанат ты тупой. ACID тебе в помощь.
Тупой ебанат, узнай что такое консистентность, потом спросишь разрешения кукарекать. Начать можешь с википедии. Вперёд.
>Ты из контекста вырываешь его фразы
>Требование консистентности относится к данным
Вот именно ты не знаешь смысла консистентности вне единственного контекста данных, и в этом меня упрекаешь, ай лолд, ну и долбоёб же ты.
Тебя уже обоссывать жалко уже
Когда ты перестанешь хлебать мочу?
Классная ответочка. На уровне пятиклассника примерно
А ты интересный поциент. Так жиденько обосраться и не подать виду это надо уметь.
Да хули интересного, есть аноны, которые аноны из-за скромности, а есть те, кто сидит анонимно из-за зашкаливающего мудачества, при котором из нормальных мест вышвыривают очень быстро. На бордах таких много, а вони они создают еще больше
Чё ещё спизданёшь.
Чё ещё спизданёшь.
Ведь REST - это буквально о том, как ресурсу (объекту) пользователь устанавливает напрямую атрибуты. Инкапсуляция, получается, идёт прямиком в жопу.
Пример.
Есть приглашение (invitation), пользователь может его принять или отвергнуть. В каждом из этих действий подключается разная логика. Например, при приёме нужно добавить пользователя как участника ивента, на который его пригласили, и разослать всем участникам уведомление о новом участнике. А в случае отказа - уведомить пригласившего.
Эти куски логики будут инкапсулированы внутри методов Invitation.accept и Invitation.refuse.
Как это будет отражено в API?
REST:
PUT /invitiations/:id
{status: "accepted|refused"}
Чем это плохо?
Во-первых, для двух весьма разных действий имеется одна точка входа, что нарушает interface segregation principle.
Во-вторых, представим что есть функционал изменения каких-то атрибутов (например, время, место) у еще не принятого invitation. Это действие в REST будет иметь точно такой же endpoint:
PUT /invitations/:id
{time: "...", place: "..."}
А если в таком запросе будут присланы одновременно все три перечисленные поля? Тут целый ворох потенциальных проблем поднимается: вызов одним запросом нескольких действий, валидация данных для них, возможно взаимоисключающие действия.
Проблему можно решить сменой интерфейса приема-отказа на
POST /invitations/:id/acceptation
POST /invitations/:id/refusal
как будто мы не действие выполняем, а создаем ресурс. Правда REST подразумевает что такой ресурс будет существовать в какой-то истории, и мы сможем посмотреть список всех приемов и отказов данного приглашения (GET /invitations/:id/acceptations), хотя мы ожидаем только единоразовое действие, да и доступ к такому списку такой нам в принципе не нужен. Выглядит как натягивание совы на глобус ради чистоты парадигмы.
Следующий вариант решения проблемы:
PUT /invitations/:id/accept
PUT /invitations/:id/refuse
что уже есть смешением REST и RPC: добираемся до нужного приглашения по REST, а инкапсулированное действие вызываем как RPC. Напоминаю, в REST глагол - только HTTP метод, в адресе же - всё существительное, в RPC же в роут попадает глагол - метод, который мы вызываем.
Интересно какой подход выбираете вы.