Если исходить из того, что пользуясь таким свойством ООП как инкапсуляция, мы скрываем от пользователя детали реализации (атрибуты), а публичный интерфейс объекта - это набор действий (методов), то встаёт вопрос о соответствии этой парадигмы подходу REST.Ведь 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 же в роут попадает глагол - метод, который мы вызываем.Интересно какой подход выбираете вы.
>>1291610 (OP)>мы скрываем от пользователя детали реализацииКак же вы заебали сраные ООПшники, сокрытие деталей реализации, как и сокрытие данных - это не инкапсуляция.>Ведь REST - это буквально о том, как ресурсу (объекту) пользователь устанавливает напрямую атрибуты.Ресурс != объект. Реализация ресурса может быть любой. Объект, группа объектов, рекорды в бд, файл, да хуй знает что еще, а может даже адовая смесь этого всего может стать одним ресурсом в REST. Ты занимаешься (как и почти все CRUDOSHLYOPI) натягиванием REST на OOP, что в корне не верно.Самый правильный способ с точки зрения REST решения данной задачи:PUT /invitations/:idtime="..."&place="..."POST /invitations/:iddecision=accepted|refusedВозвращает:201Location /invitations_decisions/:idПовторный POST возвращает 405 или 409 в зависимости от семантикиGET /invitations/:id/decisionВозвращает:303Location /invitations_decisions/:id
>>1292061Дружище, не рвись. Я правда хочу разобраться.> сокрытие деталей реализации, как и сокрытие данных - это не инкапсуляция.Интересно узнать почему ты так считаешь.>POST /invitations/:id>decision=accepted|refusedНасколько мне известно, REST велит использовать PUT когда адрес ресурса известен, а POST - когда неизвестен. Например, при создании адрес будущего ресурса еще не известен. А здесь известен, и следовательно PUT. Несогласен?И вообще, почему в первом запросе у тебя PUT, а во втором POST?
>>1292137>Интересно узнать почему ты так считаешь.Потому что по определению инкапсуляция - это объединение кода и данных в единый компонент. Про сокрытие ни слова. В REST кода никакого нет, одни данные.>И вообще, почему в первом запросе у тебя PUT, а во втором POST? Первый запрос - демонстрация API на изменение свойств приглашения.Второй запрос - демонстрация создания ресурса "решение" к приглашению. При этом сам ресурс "решение" создается в коллекции /invitations_decisions, о чем говорит ответ сервера.Можно, конечно, сделать и так:POST /invitations_decisionsinvitation_id=invitation_id&decision=accepted|refusedВозвращает:201Location /invitations_decisions/:idНо получается это как-то в отрыве от invitation и мне не очень нравится.Но тут уже погромист должен смотреть какое API лучше описывает предметную область.
>>1292292>Потому что по определению инкапсуляция - это объединение кода и данных в единый компонент. Про сокрытие ни слова. Мы вам перезвоним.
>>1292868Маня с сосача только разве что. Инкапсуляция всегда означает сокрытие деталей.>А вообще ооп ваше нахуй не нужно.Два пикрила тебе анончик.
ООП - с ним как с быдлом: все быдло, кроме меня; православное ООП только у меня, а остальные несут ересь.
>>1293006Нет, голубчик.Манямирок - это верить, что у маркетингового баззворда, который каждый крутит как хочет чем собственно и является ООП, существует какое-то строгое определение в хоть сколько-нибудь научном смысле.
>>1292868>Инкапсуляцией называют и то и другое.Потому что дебилы неграмотные.>>1292861Слава богу. Один дебил написал, обезьянки повторили.>Инкапсуляция всегда означает сокрытие деталей.Это называется абстракция, маня.
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]
>>1293099>>Инкапсуляция всегда означает сокрытие деталей.>Это называется абстракция, маня.В двух этих утверждениях нет противоречия маня.
>>1293258>В двух этих утверждениях нет противоречияТолько для тех, у кого ООП головного мозга, инкапсуляция неотрывна от сокрытия, т.е. от абстракции. У нормальных людей эти понятия ортогональны.
>>1293310>>1293527Я то раньше думал что абстрактная мамка - это просто женшина у которой есть дети, безотносительно ее цвета глаз, размера сисек и тд. Оказывается, что абстрактная мамка - это беременная женщина, инкапсулировавшая ребенка.
>>1293550Именно так и есть. Абстрактная мамка - это женщина с детьми. Остальные детали реализации, как-то цвет глаз, размер влагалища и другие, нам уже не важны, кому нужна разведенка с прицепом?>беременная женщина, инкапсулировавшая ребенка.Читай двух анонов выше.Инкапсуляция - это, например, уровни блядства, феминизма, ламповости и соответствующее им поведение.
>>1293865>блядства, феминизма, ламповостиПри этом мы даже можем менять эти параметры, например, пиздюлями, чтобы добиться требуемого поведения, но это плохо, так как ведет к сильному зацеплению и слабой связанности.
>>1293865>Инкапсуляция - это, например, уровни блядства, феминизма, ламповости и соответствующее им поведение.Звучит как Dependency Injection!Мимо хуеющий с ваших метафор
>>1293892>Звучит как Dependency Injection!Ох нет, это все свойства объекта. Имя и возраст мамаши тоже в Dependency Injection запишешь?
>>1293926Кстати, возраст мамаши, таки, инкапсулирован с мамашей, однако его доступность сильно зависит от конкретной реализации, а так же ФГМ мамаши. Может быть как закрытым для чтения (у дам такое не спрашивают), открытым для чтения (у похуистичных тян), открытым для записи (а сколько дашь?), и даже иногда константным, равным 18.
REST -- стиль организации протокола взаимодействия распределенной системы, вероятно по сети.ООП -- парадигма программирования конкретного приложения.Сущности, как легко заметить, несколько разных порядков, и конфликтовать они могут только в голове ОПа.А ИРЛ взаимодействовать RESTful могут код клиента, написанный процедурной лапшой и колбэками, сервак на ООП, который ещё дёргает хипстерский микросервис, полный монад и функциональщины./thread
>>1291610 (OP)>Ведь REST - это буквально о том, как ресурсу (объекту) пользователь устанавливает напрямую атрибуты.Долбоеб? Ресурс != объект. Клиент посылает запрос на апдейт ресурса, получает ответ об успехе или ошибке/редирект/whatever. Всё.Какие именно объекты скрываются за этим ресурсом, какие у них поля и тд - об этом клиент вообще не знает, как и деталей реализации.Зачем ты начал связывать ооп с rest это отдельный вопрос.
>>1295265В теории взаимодействовать может что угодно и как угодно. А ИРЛ 99.9% веб-девов пишут на ОО-языках, и для АПИ используют РЕСТ. И мой вопрос в том, зачем с радостью натягивать сову на глобус, если эти концепции в принципе друг другу не подходят.
>>1295785> если эти концепции в принципе друг другу не подходят.Все равно, что спиздануть "public interface ComparableHui { public double size(); } не подходит для ООП". Ну не долбоеб ли ты?
>>1295785Ты гуманитарий?Ещё раз, для совсем одарённых: REST это стиль организации АПИ, интерфейса взаимодействия с твоей программой. Послал запрос, получил ответ, грубо говоря.При этом запрос ты, сука такая, можешь составлять хоть в блокноте, а отвечать на него со стороны сервера будет гномик, выбирающий ответ в картотеке между ляжек твоей мамки. И пока ты и гномик соблюдаете ряд условий -- у вас RESTful API, лол.
>>1295785А сам гномик может быть "запрограммирован как угодно", это тебя, пидор с блокнотиком и запросами, вообще никак не ебёт.В общем случае на стороне сервера, между интерфейсом (гномиком слушающим твои запросы) и непосредственным источником возвращаемых данных может быть пять слоёв абстракций и пара обращений к сервисам. И это, опять же, к RESTу уже никакого отношения не имеет. Ты сделал запрос GET-мамка/входящие, и это уже дело гномика сделать SQL запрос к расписанию мамки, или обратиться ко гномику поглубже, который знает лучше, или это монолитный мудрец-гном, который всё как мудак хранит в памяти, в синглтон объекте.
>>1295785Ах да, и если ты реально написал свой первый хелловорлд на ООП-языке, и он у тебя плохо натянулся на REST-глобус, то изволь привести код и объяснить, где сове жмёт.Анон поглядит, и пять к одному, что дело не в ООП
>>1296069Не могу понять, неужели я так сложно объяснил суть моих претензий к спайке REST и ООП? Попробую еще раз. REST - это манипулирование данными через установку атрибутов ресурса, а ООП - через вызов методов ресурса (объекта). Способ манипулирования REST противоречит концепции инкапсуляции, принятой в ООП. Соединять их - ненатурально. Так зачем делать это?Мне кажется со мной спорят аноны с синдромом утенка, у которых вызывает отторжение сама мысль, что есть и другие варианты.>>1296080Первый хелловорлд на ООП-языке я написал лет 18 назад.Пример кода я привел в ОП-посте, сожалею что спустя 40 постов ты всё ещё не смог его осилить.
>>1296169>Не могу понять, неужели я так сложно объяснил суть моих претензий к спайке REST и ООП? Попробую еще раз. REST - это манипулирование данными через установку атрибутов ресурса, а ООП - через вызов методов ресурса (объекта). Способ манипулирования REST противоречит концепции инкапсуляции, принятой в ООП. Соединять их - ненатурально. Так зачем делать это?Инкапсулируются только те атрибуты, который необходимо инкапсулировать. Например такие, которые системные, нужны для работы класа.Остальные атрибуты делаются публичными.>ООП - через вызов методов ресурса (объекта)Через вызов методов и аттрибутов объекта
>>1296169> Пример кода я привел в ОП-посте, сожалею что спустя 40 постов ты всё ещё не смог его осилить.> В ОП-посте описание REST интерфейса и ни строчки кода, ни класса, ни какой имплементации.Знаешь, есть ты за 18 лет не разобрался в архитектуре сложнее однострочника, в котором хранилище данных и сетевой интерфейс как-то напрямую взаимодействуют, то всё очень-очень плохо
>>1296169>REST - это манипулирование данными через установку атрибутов ресурсаНу что за маняфантазии? Ты читал вообще что такое REST? Там ни слова про установку атрибутов ресурса, про то, что у ресурса должны быть какие-то атрибуты, а так же нет конкретного механизма изменения ресурса.
>>1296436>Ты читал вообще что такое REST? Там ни слова проУ РЕСТ нет спецификации, поэтому начнем с того, где "там".
И где ты увидел что я ресту приписываю конкретный механизм изменения ресурса. Свой вопрос я задал явно и конкретно, пиздоглазый утёнок.
>>1296449РЕСТ - это набор ограничений для построения хорошего, годного АПИ и среди этих ограничений нет ничего подобного, о чем пишет ОП.>>1296448Это уже детали конкретной реализации. Это могут быть как атрибуты, так и любые другие сущности - команды, функции, действия и вообще какие угодно сущности. И если кто-то где-то нарушает инкапсуляцию, так это сам программист, который тупо выставил наружу все кишки своей программы, вместо того, чтобы придумать интерфейс.
>>1296568Ты так и не ответил где "там".>Это уже детали конкретной реализации. Это могут быть как атрибуты, так и любые другие сущности - команды, функции, действияОпять нет конкретного ответа.Если ты понятия не имеешь про РЕСТ, можно просто не захламлять эфир белым шумом.
>>1296604>Ты так и не ответил где "там".В определении REST и RESTful system, блять, тупое ты создание. Открой хотя бы википедию и прочти про это.>Опять нет конкретного ответа.А что конкретного можно ответить на твой абстрактный пример? Хуй знает какая там семантика у твоего JSON сообщения. Но, обычно, методом PUT заменяют коллекцию ресурсов, или один конкретный ресурс на другой. Но REST тебя к этому не обязывает.
>>1296672>А что конкретного можно ответитьЧто ответить не знает, но своё авторитетное мнение зачем-то пихает. Типичный школьник.
>>1296676Мальчик мой, я в этой индустрии уже более 10 лет. И поверь мне, ты бы у меня даже джуном ни дня не продержался бы — моментально был бы уволен за некомпетентность. Так что прикрой свой ротешник и прекрати позориться.
>>1296737Сейчас рассматриваю его, и понимаю что не во всех случаях он нужен, REST/RPC проще и зачастую их хватает. Может я ошибаюсь, поправь. Алсо, что скажешь насчет GRPC?
>>1291610 (OP)> в REST глагол - только HTTP метод, в адресе же - всё существительноеТакое ограничение действительно не дает тебе использовать url для отправки сообщения объекту (если твой ресурс - объект). Но у меня возникает вопрос - откуда ты его взял? Я перечитал в вики 6 основных ограничений REST и не нашел там его.> PUT /invitiations/:id> {status: "accepted|refused"}А чтение клиентом статуса в твоей системе возможно? Если да - то он у тебя все равно наружу торчит, вот такое вот ооп, лол. Вообще тред очень жирный, спасибо, оп. Прям как ооп-треды в старые добрые времена почти.
>>1291610 (OP)Этот весь тред, на самом деле, полный пиздец. Пиздец как начиная с самого REST (если кто не в курсе - это всего лишь прикладной протокол поверх HTTP из которого смузипетушня сделала какую-то религию), так и с вопроса ОП хуя а не запрещено ли религией жрать свинину не противоречит ли протокол прикладного уровня объектно-ориентированному программированию.
>>1298718>если кто не в курсе - это всего лишь прикладной протокол поверх HTTP из которого смузипетушня сделала какую-то религиюПричем, самая мякотка в том, что протокола на самом деле никакого нет - это по-сути просто такие сорт оф уголовные понятия (то есть определен только на словах, трактуемых каждым по-своему без какой-либо спецификации и механизмов валидации) про то как кошерно хипстопидору в 2к0Х-2к1X пердолить протокол HTTP.
>>1291610 (OP)> Если исходить из того, что пользуясь таким свойством ООП как инкапсуляция, мы скрываем от пользователя детали реализации (атрибуты), а публичный интерфейс объекта - это набор действий (методов), то встаёт вопрос о соответствии этой парадигмы записи в файл и чтению из файла.> Ведь работа с файлами - это буквально о том, как ресурсу (файлу) пользователь устанавливает напрямую содержимое. Инкапсуляция, получается, идёт прямиком в жопу.> Если исходить из того, что пользуясь таким свойством ООП как инкапсуляция, мы скрываем от пользователя детали реализации (атрибуты), а публичный интерфейс объекта - это набор действий (методов), то встаёт вопрос о соответствии этой парадигмы сетевому взаимодействию.> Ведь сетевое взаимодействие - это буквально о том, как ресурсу (сокету) пользователь устанавливает напрямую передаваемые данные. Инкапсуляция, получается, идёт прямиком в жопу.
>>1298718>REST (если кто не в курсе - это всего лишь прикладной протоколКакой это тебе, нахуй, протокол? REST - набор ограничений, которые можно наложить хоть на HTTP, хоть на твою мамашу-шлюху, чтобы она превратилась в RESTFul web-service.
>>1298692> Но у меня возникает вопрос - откуда ты его взял? Я перечитал в вики 6 основных ограничений REST и не нашел там его.Хм, его знают все, кто работает с рест. Это базовое отличие от RPC. Можешь заглянуть сюда например https://restfulapi.net/resource-naming/>>1298692>А чтение клиентом статуса в твоей системе возможно? Клиентом чего, апи класса или апи, предоставляемом по сети как сервис?
>>1299738По ссылке дается определение ресурса, довольно четкое. Думаю, если ОП прочитает его, он больше не станет задавать идиотских вопросов.
>>1299738>>1299738>Хм, его знают все, кто работает с рест. Это базовое отличие от 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.
>>1300194Я и есть ОП. Как видишь, учу РЕСТу местных макак, которые считают что они знают лучше меня лол.
>>1300197>>1300205Лол. Вы читали вообще ссылку?Во-первых: >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" вас не навели ни на какую такую мысль.
>>1300901Ты неисправимый дегенерат. Даже после того, как тебя ткнули носом в твоё же дерьмо, ты продолжаешь лолкать и тупить дальше. Лучше бросай погромирование, не твое это (если ты не ребенок 15-25 лет, конечно - тогда еще есть шанс).
>>1301236Есть, да только ты не услышишь. Ты швырнул в меня текстом, в котором черным по белому написан ответ на твой вопрос, но ты неспособен его увидеть, так как вычитываешь из текста только, что, как тебе кажется, подтверждает твое поганое мнение.Осилишь сам показать мне, где обосрался в своем последнем посте, чванливый кусок говна - я тебе помогу, нет - тебе уже никто не поможет, разве что кадровичка по приказу уставшего терпеть твои косяки руководства сделает за тебя то, на что у тебя самого не хватит яиц.
>>1301285Пиздец ты ебанутый.>>1301275Для этого надо придумать некий ресурс, который ты якобы создаешь этим действием. Например, назвать такой ресурс action, и выразить действие какPOST /actions{action_type: "kill_enemy_and_take_his_money", enemy_id: XXX}
>>1301275POST /person/1/killЭто переведет врага в статус "труп" и наделит текущего пользователя эксклюзивным правом распоряжаться своими зависимыми ресурсами.POST /person/1/money/give{"target" : /person/2}Мертвый враг отдает деньги кому сказано.
>>1300901Тебя тут английским языком призывают не смешивать два архетипа в одном ресурсе. А ты уже начал фантазировать, что контролер не подходит под определение REST.>>1301275Я бы сделал как то так: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}"
>>1301309>Я бы сделал как то так:>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}" АЗАЗАЗАЗА СТЕЙТ НА СЕРВИРЕ, ТВОЙ РЕСТ НЕ РЕСТ))))))
>>1301309>{actions: ["/corpse/{id}/examine", "/corpse/{id}/dismember", "/corpse/{id}/burn" ...]}Это процедуры, а не ресурсы. RPC, которое мечтает быть REST-ом.
>>1301647ОП, тебя еще недостаточно обоссали за твои тупость и неумение читать? Ресурсу ничто не мешает быть процедурой.
>>1301653Ну пока что ты ссышь себе в рот не переставая, почему меня это должно смущать. Сейчас ещё и обсеришься объясняя разницу между RPC и REST, а потом обмажешься несвежим говном рассказывая какие действия ты можешь сделать с процедурой как REST-ресурсом. Вперёд.
>>1301491Хомячки возводят stateless в абсолют. REST всего-лишь ограничивает способ хранения стейта клиента: история взаимодействия с ресурсами, данные аутентификации итд. Сервер должен быть свободен от этого дерьма, а клиент должен сам нести свое бремя.>>1301647Ок. Покажи где такое написано в определение REST, что процедуры - не подмножество ресурса, и вообще так нельзя.
>>1291610 (OP)>Ведь 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/acceptedPUT /invitations/:id/refusedИ это будет лучший способ.
>>1296169>Не могу понять, неужели я так сложно объяснил суть моих претензий к спайке REST и ООП? Попробую еще раз. REST - это манипулирование данными через установку атрибутов ресурса, а ООП - через вызов методов ресурса (объекта).Не понятно, почему ты так дрочишь на ООП.Нет, вот эти твои претензи - хуйня полная. ООП - это посылка сообщений объекту, который обладает внутренним состоянием. Объект не гарантирует, что он твое сообщение не выкинет. Он вообще тебе ничего не гарантирует. Потому что он инкапсулирован и у него лапки.С REST то же самое. Послать сообщение серверу ты можешь. А все остальное инкапсулировано.Поэтому концепции хорошо ложатся друг на друга. Ты просто считаешь, что у тебя объект один, приглашение. На самом деле у тебя объектов два - приглашение на клиенте и приглашение на сервере. И тебе нужно сделать так, чтобы у этих объектов было согласованное состояние. Поэтому если локально ты делаешь процедуру object.accept и object.refuse и не паришься, то при появлении посредника в виде HTTP у тебя появляются проблема передачи состояния.Так что REST и ООП прекрасно работают. Другой вопрос, что ты не замечаешь других слонов, например ORM. Веб строится вокруг реляционных БД, которые на ООП натягиваются действительно очень хуево, потому что записи в БД на самом деле иммутабельны и меняются только после успешной транзакции.Нормальные люди поняли, что ООП сдохнет еще в девяностые, в 2018 это не очевидно только непрофессионалам типа авторов книжек и преподавателей вузов. Гуйня когда-то была вотчиной ООП, сейчас в моде реактивность, С++ умер и остался только на высокопроизводительных приложениях, где используется dataflow-подход, веб становится асинхронным, в жабе от ООП осталось одно название. Из новых языков типа rust или go выпилено наследование. ООП это вообще не так вещь, относительно которой следует плясать и крутиться.
>>1301695А своими мозгами подумать не хочешь? Чем этот "REST" отличает от "RPC" и какие манипуляции кроме call можешь над процедурой делать расскажешь?>>1301706>По-твоему и поля геттеры и сеттеры в жабе нарушают инкапсуляциюСеттеры нарушают безусловно. Жаба это в принципе кусок вонючего говна, ты зря решил её привести в пример.>хотя это не так: объект сам решит, апдейтить ему себя, или нетЕсли под "апдейтить" подразумевается что в методе-сеттере есть какая-то бизнес-логика, то это уже не сеттер, а бизнес-логика.> смотри на твоем примере: клиент залогинен с компа и телефона, на компе он вызывает RPC-процедуру принятия приглашения, ему придет ответ, мол, все ок, а телефон об этом как узнает? Никак. Поэтому помимо acceptInvitation()/refuseInvitation() тебе нужна будет функция getInvitationInfo(), и еще немного подумав ты сделаешь аналог REST, просто на RPC.И в чем проблема, в третьей функции? Как REST решает эту её? Можешь привести аналог на REST?>Действие одно и то же - апдейт состояния ресурса.Вот в этом месте как раз явно видно противоречие с принципом инкапсуляции. Для объекта это два разных пути развития бизнес-логики, с очень разными последствиями, будут вызваны два разных метода а для REST - всего лишь апдейт одного поля.>в хранении списка всех приемов и отказов данного приглашения ничего плохого нет.Оно просто НИНУЖНО. Нет такого требования в спецификации.>RPC - это будет лучший способ.Я о том и толкую, что RPC гораздо чаще удобней чем REST, а у местных утят дупа горит от мысли что на швитой REST покусились. Ну молодец что первым допетрил логически.
>>1301715>На самом деле у тебя объектов два - приглашение на клиенте и приглашение на сервере. И тебе нужно сделать так, чтобы у этих объектов было согласованное состояние. >Нет нарушения инкапсуляцииТы наверно и в ОО-коде вместо методов бизнес-логики вызываешь сеттеры из любого места ¯\_(ツ)_/¯
>>1301716>А своими мозгами подумать не хочешь? Чем этот "REST" отличает от "RPC" и какие манипуляции кроме call можешь над процедурой делать расскажешь?Ясно-понятно. Найти такого ограничения на ресурс не можешь. Если ты сам себя убедил в том, что ресурс - это ООП объект с кишками наружу, то это не значит, что это действительно так и есть.Что касается разницы RPC и REST, то она чисто семантическая.POST /enemy/{id}/kill в RPC означает вызов процедуры, а в REST - создание нового ресурса.
rpc типа wsdl: есть чёткое описание методов, параметров, ответаrest: нет даже списка методов и возможных операций.Можно ли делать put на "товар" - хуй знает. Что оно на самом деле делает - хуй знаетСравните addPurchareToBacket(purchare, basket) - всё просто и понятно. А как через рест? Пут или пост? Корзина или товар?
>>1301655Все уже разжевано по твоей же ссылке вдоль и поперек, твоя клоунада выглядит жалко. Тебя уже несколько человек в говно макнули, сколько тебе еще надо?
>>1301730>Можно ли делать put на "товар" - хуй знает.Знатоки, блять, REST over HTTP собрались тут.Есть запрос специальный. Называется OPTIONS, который и вернет тебе требуемое описание, или даже кусок кода.
>>1301741зачем вообще бизнес-логику пытаться натягивать на транспортный протокол? Давай тогда сразу tcp командами хуячить
>>1301727>Что касается разницы RPC и REST, то она чисто семантическая.>POST /enemy/{id}/kill в RPC означает вызов процедуры, а в REST - создание нового ресурса.Лол бля. Включай мозги, просвещайся.https://www.smashingmagazine.com/2016/09/understanding-rest-and-rpc-for-http-apis/
>>1301757Ну зойчем ты себя каждый раз макаешь в дерьмо? Ты мазохист чтоле?Из твоей же ссылки:>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.
>>1301772Ай лолд. Говноед, ты когда на два банальных вопроса ответишь, получишь разрешение кукарекать про конструктив.
>>1301756>HTTP HTTP (англ. HyperText Transfer Protocol — «протокол передачи гипертекста») — протокол прикладного уровня передачи данных (изначально — в виде гипертекстовых документов в формате «HTML»Протокол передачи html страничек
>>1301716>Сеттеры нарушают безусловно.Нет. Нарушением инкапсуляции будет выставление публичных полей, когда объект не может проконтролировать пенетрацию в свое нежное тельце. Когда у тебя есть сеттер, сегодня он просто выставляет поле, завтра форматирует жесткий диск, тот, кто посылает сообщение объекту об этом не знает.>Если под "апдейтить" подразумевается что в методе-сеттере есть какая-то бизнес-логика, то это уже не сеттер, а бизнес-логика.Ты можешь назвать ее йобампампацией, суть не изменится: вызывая йобампампацию ты не нарушаешь инкапсуляцию. Чтобы ее нарушить, нужно сделать публичным поле объекта. В случае 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. invitation2. список accept'ов и refuse'овИ станет совсем хорошо.
>>1301748ООП - объекты с внутренним состоянием, обменивающиеся сообщениями. Годится для моделирования всяких систем.В жабе у тебя будет https://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.htmlТам большей частью объекты и интерфейсы костыли для странной системы типов жабы, а сам код вообще не ООП
>>1301798И как это противоречит тому, что я сказал, и подтверждает твой тезис, что это транспортный протокол?
>>1301808>Все, заебись. И тут блядь ты смотришь и видишь, что 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_idupdate_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
>>1301816Транспортный протокол называется TCP/IP. HTTP - прикладной протокол, довольно высокоуровневый. То, что его превратили в "GET когда параметры в запросе и POST когда параметры хочешь скрыть" - это печально.
>>1301823>его превратили в "GET когда параметры в запросе и POST когда параметры хочешь скрыть"Настало время охуительных историй.А куки в заголовках, так вообще пиздец?
>>1301808>Нет. Нарушением инкапсуляции будет выставление публичных полей, когда объект не может проконтролировать пенетрацию в свое нежное тельце. Когда у тебя есть сеттер, сегодня он просто выставляет поле, завтра форматирует жесткий диск, тот, кто посылает сообщение объекту об этом не знает.>Ты можешь назвать ее йобампампацией, суть не изменится: вызывая йобампампацию ты не нарушаешь инкапсуляцию. Чтобы ее нарушить, нужно сделать публичным поле объекта.Ок, согласен. Тогда, если по 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.
>>1301859Это протокол позволяет выразить твою бизнес логику в терминах HTTP запрос/ответ.Причем протокол написан так, что клиент может вообще нихуя не знать об API сервиса, но запросив базовый урл, узнать все, что нужно для движения дальше, вплоть до получения исполняемого кодабраузеры с js, сука, так и работают.
>>1301817>поленился ПОЛЕНИЛСЯпосоны, мать его в сраку, ПОЛЕНИЛСЯА не ленился, то в бинарных кодах бы написал
>>1301881>Это протокол позволяет выразить твою бизнес логику в терминах HTTP запрос/ответ.а с помощью tcp так сможешь? Там тоже куча кодов, которых можно привзять к бизнес-логике
>>1301843>Ок, согласен. Тогда, если по 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 nounREST это 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.А они не отдельно. Это непрерывный спектр различных возможностей.
>>1301903Это еще мягко сказано. Вконтакте написан на пхп криворукими обезьянами, которые до сих пор не сделали нормальный поиск музыки.
>>1301913>сначала вызовите malyYoba, потом bolshoYoba, если наоборот, работать не будет>>1301309POST /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}"
>>1301904>а с помощью tcp так сможешь?Если ты думаешь, что tcp находится на том же уровне абстракции, что и http, то у меня для тебя плохие новости.
>>1301920они оба нужны для передачи данных. При этом их служебные команды нельзя использовать в каких-то других целях.Например 404 всегда должно означать отсутствие ресурса по такому адресу, но никак не отсутствие пользователя или что у него нет денег
>>1301918В данном случае ты не сможешь запросить ресурсы в обратном порядке вообще никак. Потому что ты не знаешь о существующем ресурсе. Так что мимо. А в рпц сможешь.
>>1301923Application layer нужен для передачи данных между приложениями, или кусками приложения. В то время как TCP выполняет крайне низкоуровневую задачку по гарнтированной доставке вообще любых данных.>Например 404 всегда должно означать отсутствие ресурса по такому адресу, но никак не отсутствие пользователяЕсли пользователь, или деньги абстрагированы до понятия ресурс, то почему нет?
>>1301913>Если хочется соблюсти "один запрос - одно действие" Не "хочется", а это суть ООП, для этого придумали композицию объектов.>ну так запрети послылать PUT /resource {status: X, quantity: Y}, и возвращай 500, а только PUT /resource {status: X} и PUT /resource {quantity: Y} отдельноЕдиная точка входа для кучи разномастных действий. Контроллер, который владеет информацией о внутреннем устройстве моделей, знает какие действия можно сочетать, какие нет. Звучит просто кайф.>Не путаю.Путаешь.>ООП не запрещает побочные эффекты при апдейте внутреннего состояния объектаКачество твоего ООП-кода понятно. Только "Он просит его апдейтнуться, а объект форматирует жесткий диск" - это пиздец. Если тебе надо форматировать жетский диск, ты просишь форматировать, а не апдейтиться.>Все наоборот.Нет не наоборот. Всё, что в КРУД (который путаешь с РЕСТ) не попадает, требует искуственных извращений, которые описаны в ОП-посте.Вот такой говнокод например >>1301918В котором можно сделать сначала /dismember, потом /burn, но никак не наоборот. Такой-то stateless REST.
>>1301926Define "реальный 404"Если ты имеешь ввиду что-то типа:GET /users/1404То, прежде чем попасть по этому урлу, ты должен был зайти наGET /usersOKВ таком случае нет юзера.А в таком:GET /users404Тебе бы вообще не следовало соваться в GET /users/1
>>1301647>Это процедуры, а не ресурсы. 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 действие только одно - вызов.
>>1301931>В котором можно сделать сначала /dismember, потом /burn, но никак не наоборот. Такой-то stateless REST.Это список доступных действий, а не последовательность, лол.
>>1301933>Ему нужно вынести глаголы в параметры запроса. Убийство это не POST, а DELETE с возвратом URI трупа.И все, кто не были синхронно оповещены о создании corpse, больше никогда не найдут enemy по его id.Вопрос со звездочкой: если DELETE - это убить, как реализовать ранение?
>>1301933>DELETE с возвратом URI трупа.Ебать, с кем я на одной борде сижу. Какой возврат URL после DELETE? Ничего не попутал?По вызову /enemy/{id} после kill может быть, например, 301 MOVED PERMANENTLY /corpse/{id}, а может OK и в каком-нибудь поле будет killed.
>>1301940>Какой возврат URL после DELETE? Ничего не попутал?Твоё же говнецо:>DELETE /enemy/{id}?kill>В ответе:>"/corpse/{id}">запрос к DELETED ресурсу>301 MOVED PERMANENTLY>а может OK
>>1301939>Т.е. можно расчленить труп, который ранее был сожжен?А если его кто-то другой сжёг между твоими get и post? Если действие более недоступно, то возвращается 406. А по новому get вернется новый список действий, например.
>>1301938>И все, кто не были синхронно оповещены о создании corpse, больше никогда не найдут enemy по его id.Ну тащемта он убит>Вопрос со звездочкой: если DELETE - это убить, как реализовать ранение? Ранение меняет стейт, значит PUT>>1301940В чем проблема? DELETE может возвращать body, и там можно дать на ссылку с трупом, а остальным уже возвращать 404.
>>1301946Но это жы REST, там в принципе не может быть такого как в RPC>RPC может быть stateful и требовать каких-то изощренных протоколов (сначала вызовите malyYoba, потом bolshoYoba, если наоборот, работать не будет)
>>1301931>Не "хочется", а это суть ООП, для этого придумали композицию объектов.Нет. Когда ты сразу кучу вещей апдейтишь разом, это - транзакция, и это удобно, особенно когда у тебя ресурс может апдейтиться конкурентно.Типа, допустим ты редактируешь статью на википедии, и что, посылать изменение каждого поля отдельным запросом? Охуенно будет, когда 2 человека начнут что-то делать одновременно.>Единая точка входа для кучи разномастных действий. Контроллер, который владеет информацией о внутреннем устройстве моделей, знает какие действия можно сочетать, какие нет. Утверждение уровня "http-сервер знает о внутреннем устройстве моделей". С чего ты взял?>Путаешь.Нет, не путаю.>Качество твоего ООП-кода понятно. Я не пишу ООП код, я унижал ООП-манек на бордах еще в 2010.>Всё, что в КРУД (который путаешь с РЕСТ) не попадает, требует искуственных извращений, которые описаны в ОП-посте.Там нет каких-то извращений. Стоило только немного напрячь мозг и ты пришел к правильному решению.>В котором можно сделать сначала /dismember, потом /burn, но никак не наоборотНельзя. После /burn ресурс просто не вернет тебе в списке actions dismember.
>>1301947>>И все, кто не были синхронно оповещены о создании corpse, больше никогда не найдут enemy по его id.>Ну тащемта он убитИ к профилю убитого доступа больше нет. Вся информация об убитом становится недоступной, ведь он удолен как ресурс.>>Вопрос со звездочкой: если DELETE - это убить, как реализовать ранение? >Ранение меняет стейт, значит PUTPUT для идемпотентных запросов. Ещё попытка.
>>1301951>Но это жы REST, там в принципе не может быть такого как в RPCКакого такого?Stateful означает существование разделяемого состояние клиент-сервер. Stateless - сервер не знает о состоянии клиента, клиент с каждым запросом ему сообщает все, что серверу требуется для обработки запроса, куки-хуюки. Это все не мешает быть самому серверу stateful.>>1301952>Я не пишу ООП код, я унижал ООП-манек на бордах еще в 2010.Егорку хоть уважаешь?
>>1301954>И к профилю убитого доступа больше нет. Вся информация об убитом становится недоступной, ведь он удолен как ресурс.Ну да. Ты мертвых видел когда-нибудь?>PUT для идемпотентных запросов.А ты помимо установления флага "ранен" хочешь уменьшать его банковский аккаунт на величину урона? Ну так ТЗ надо изначально грамотно составлять.
>>1301952>>Не "хочется", а это суть ООП, для этого придумали композицию объектов.>Нет. Когда ты сразу кучу вещей апдейтишь разом, это - транзакция, и это удобно, особенно когда у тебя ресурс может апдейтиться конкурентно.Ты сперва написал `Если хочется соблюсти "один запрос - одно действие"`, а теперь - `Когда ты сразу кучу вещей апдейтишь разом, это - транзакция`.Так вот. Один запрос HTTP - одно действие (метод) бизнес-логики. Когда по REST API присылают набор атрибутов, и для установки каждого вызывается отдельный сеттер с бизнес-логикой внутри - это кусок вонючего говна. Потому что правил о том, какие атрибуты можно присылать вместе, а какие нет, и в каком порядке - их нет. А если их делать, то нахуя этот цирк нужен.>>Единая точка входа для кучи разномастных действий. Контроллер, который владеет информацией о внутреннем устройстве моделей, знает какие действия можно сочетать, какие нет. >Утверждение уровня "http-сервер знает о внутреннем устройстве моделей". С чего ты взял?Если в моделях меняется логика, и сеттеры, который раньше вызывались в порядке A->B, больше в таком порядке вызываться не могут, то потребуется в контроллере менять логику проверки присланных данных. http-сервер менять не придется.>Я не пишу ООП код, я унижал ООП-манек на бордах еще в 2010.Понятно что с таким качеством кода тебя выгнали на мороз еще в 2010.>Там нет каких-то извращений.Ну опять же хорошо что тебя с 2010 не подпускают к коду.>>В котором можно сделать сначала /dismember, потом /burn, но никак не наоборот>Нельзя. После /burn ресурс просто не вернет тебе в списке actions dismember.Правильно. Если хочешь сделать в одной сессии оба действия, так и будет, а если в разных - WRONG. Такой-то stateless, REST порешал проблему присущую лишь RPC.
>>1301955>>Но это жы REST, там в принципе не может быть такого как в RPC>Какого такого?Ты слепошарый? Повторяю цитату какого:>RPC может быть stateful и требовать каких-то изощренных протоколов (сначала вызовите malyYoba, потом bolshoYoba, если наоборот, работать не будет)>>1301957Уверен.>>1301958>Ну да. Ты мертвых видел когда-нибудь?И видел, и имена их помню, и к вещам их у меня доступ есть. Включи башку:DELETE /player/X -> OkGET /player/X/profile -> 404
>>1301958>А ты помимо установления флага "ранен" хочешь уменьшать его банковский аккаунт на величину урона? Ну так ТЗ надо изначально грамотно составлять.Давай составим. Надо нанести ранение с определенной силой. У игрока, которого ранят, отнимется энергия на величину зависящую от силы ранения и каких-то его внутренних состояний. Вперёд.
>>1301971>Ты сперва написал `Если хочется соблюсти "один запрос - одно действие"`, а теперь - `Когда ты сразу кучу вещей апдейтишь разом, это - транзакция`.Ну да. Хочется так - делаешь так, хочется так - делаешь так. Это не религиозные догматы.Это ты пытаешься кому-то что-то запретить, теперь, оказывается, разные поля ресурса нельзя апдейтить одним запросом. Реальный мир устроен не так и шаблоны не загоняется. Ты скажи, что конкретно тебе нужно и тогда можно будет подумать, что можно сделать. Как в примере с трупом. А не какие-то абстрактные контроллеры, реализацию которых не ты видишь через жопу, а я в чем-тоне прав.>Один запрос HTTP - одно действие (метод) бизнес-логикиНу то есть статья на википедии должна модифицироваться серией POST запросов, сначала меняем заголовок, потом тело статьи, потом имя автора и т. д.Или же юзера нужно обязать менять сразу все - статья на мегабайт, нужно поменять заголовок, но нет, мы будет гонять весь ее текст по сети.>Понятно что с таким качеством кода тебя выгнали на мороз еще в 2010.У меня неплохой код, я же не пишу ООП>Если хочешь сделать в одной сессии оба действия, так и будет, а если в разных - WRONG.Где ты сессии взял. У нас есть запросы и все. Если они разнесены во времени, то проблем нет. Если они идут одновременно, например1. юзер1 делает get2. юзер2 делает get3. юзер1 вызывает метод1 и меняет стейт4. юзер2 вызывает метод2 и меняет стейт, а он больше ресурсом не поддерживаетсяТо юзер2 получит ошибку в лоб. Се ля ви.А если ты хочешь, чтобы такого не было, пили полностью stateless систему, которая возвращает новые URI в ответ на юзерские модификации.>Такой-то stateless, REST порешал проблему присущую лишь RPC.Проблему конкурентности решают только транзакции, которые по твоим догмам делать нельзя
>>1301975А давай ты нахуй пойдешь? Ты напоминаешь хуя с видео про иммолейт импрувед. Ох ебать, я не знаю какие-то тонкости HTTP, перепутал запросы и земля налетит на небесную ось. Ага.Программист может совершить какие-то архитектурные ошибки, но это не выбор между PUT, POST или даже GET?action="apdeyt". Это вообще похуй.
>>1301973>Ты слепошарый? Повторяю цитату какого:А ты?Повторяю цитату ответа:>Stateful означает существование разделяемого состояние клиент-сервер. Stateless - сервер не знает о состоянии клиента, клиент с каждым запросом ему сообщает все, что серверу требуется для обработки запроса, куки-хуюки. Это все не мешает быть самому серверу stateful.
>>1301986>Это ты пытаешься кому-то что-то запретитьLOL.>Ты скажи, что конкретно тебе нужноС чего ты взял что мне что-то конкретно нужно.>>Один запрос HTTP - одно действие (метод) бизнес-логики>Ну то есть статья на википедии должна модифицироваться серией POST запросов, сначала меняем заголовок, потом тело статьи, потом имя автора и т. д.Статья на википедии это формошлепство, оно неинтересно и тут REST делает своё дело. Можешь пофантазировать с примером убийства и ранения игрока.>>Если хочешь сделать в одной сессии оба действия, так и будет, а если в разных - WRONG.>Где ты сессии взял. Вот где:>>Нельзя. После /burn ресурс просто не вернет тебе в списке actions dismember.>После /burn>После /burn>После /burn>транзакции, которые по твоим догмам делать нельзяЭто не мои догматы, а твои фантазии, транзакций даже не касался.>>Такой-то stateless, REST порешал проблему присущую лишь RPC.>Проблему конкурентности решают только транзакцииОткуда ты проблему конккурентности уже высрал? Речь о проблеме с этиъ твоих слов >RPC может быть stateful и требовать каких-то изощренных протоколов (сначала вызовите malyYoba, потом bolshoYoba, если наоборот, работать не будетПосле /burn ничем не напоминает.
>>1301971>А если их делать, то нахуя этот цирк нужен.Сеттеры и геттеры - это, как правило, само по себе говно вне предметной области задачи. Какая архитектура у приложухи, такое и РЕСТ АПИ.
>>1301990Ну только эта цитата никак не объясняет почему RPC-шное>сначала вызовите malyYoba, потом bolshoYoba, если наоборот, работать не будетбогомерзко, а REST-вое>После /burn ресурс просто не вернет тебе в списке actions dismember.где этот список actions надо откуда-то высирать, если /burn вызывал не ты и/или не сейчас - это благодать.
>>1302002>где этот список actions надо откуда-то высирать,Ну что ты такой тугой-то?Когда ты попросишь (давно известный тебе) POST /enemy/1/burn ,тебе вернется 410, и если ты все еще хочешь поизмываться над трупом, то тебе придется запросить, GET /enemy/1, а в ответ придет 200 {actions: ["collect_ash"], status: "burned"}
>>1302007Лишний запрос делать? Круто.>POST /enemy/1/burnPOST-запрос создаёт ресурсы. Какой ресурс ты создаешь в данном случае, сжигание? Т.е. одному enemy в качестве вложенных ресурсов может принадлежать 1 сжигание, 1 расчленение, 1 повешение, 1 утопление в кислоте и так далее.Т.к. этих ресурсов может быть только по одному, то создание их идемпотентно, значит использовать надо PUT /enemy/1/burn вместо POST, не?Когда захотим проверить есть ли у enemy тот или иной ресурс, будем проверять наличие вложенного ресурса пока не наткнемся на один из:GET /enemy/1/burnGET /enemy/1/dismemberGET /enemy/1/hangGET /enemy/1/aciddrownКруто, чо.>actions: ["collect_ash"]Какой и почему HTTP метод? Как называется данный ресурс? (подсказка: это не ресурс, а процедура, с ней можно сделать только одно действие - вызвать, поэтому HTTP метод и не указан. RPC, которое утята считает REST кек).
>>1301996>LOL.Перечитай свои посты. Такой проповедник с кучей догматов.>С чего ты взял что мне что-то конкретно нужно.Ну если тебе ничего не нужно, зачем ты что-то пишешь? Удобная позиция, как только тебе задают конкретику "ой мам, я тут тралю на самом деле".>Статья на википедии это формошлепство, оно неинтересно и тут REST делает своё дело.Логическая уловка "ненастоящий шотландец". Пакетное изменение свойств это банальная вещь, и принципиально это от убийства и ранения не отличается - модифицируется стейт.>Откуда ты проблему конккурентности уже высрал? Речь о проблеме с этиъ твоих слов Потому что я более опытный программист. Если у тебя в API появляется подобная хуйня с важностью порядка запросов, пили транзакционность.>После /burn ничем не напоминает.Любое stateful API будет иметь подобные издержки. Можно положить деньги, а потом снять, но не наоборот. Когда я писал про извращенные RPC-протоколы, я имел в виду далеко не это. Вот посмотри тут https://vk.com/dev/upload_files - чтобы загрузить файл нужно вызвать 4 метода, а не один. И попробуй так извратиться, если у тебя REST. Там что-то сложнее одного PUT запроса не будет - а сервер уже должен ебаться с остальным.
>>1302022>Перечитай свои посты.Сейчас, подожди, раз ты сказал, то я приготовлю себе большую чашку чая, усядусь поудобнее и буду перечитывать свои посты. 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
>>1302020>Какой и почему HTTP метод?REST можно и на одном GET?action=... сделать.Ты реально лингвист какой-то. То из того, что анон вместо "POST /enemy/1?burn" пишет "POST /enemy/1/burn" делаешь многозначительные выводы, то тебя ебет какой HTTP-метод, как будто это что-то меняет.
>>1302033Нет, это ты быдло, которое за синтаксисом не видит семантики. Слэш вместо вопросительного знака - все, пиздарики, ваш рест не рест, ведь burn это не ресурс, во как я вас поймал
>>1302034Долбоёб, где я писал что нужен вопросительный знак? Ты сам это придумал и сам с этим споришь. Я подсказку написал русским языком, прочитай, дятел.
>>1302038Алло, это я тебе написал, что там нужен вопросителньый знак. burn - это не ресурс, это параметр POST запроса, который меняет соответствующий стейт ресурса. Нет, это не RPC. Да, на RPC так тоже можно. Потому что RPC мощнее и может все, что может REST по определению.
>>1302029>Передо мной встал вопрос противоречия концепций REST и OOP. Я его тут обсуждаю. Проблемс?Нет, занимаешься унылой демагогией, потому что всю твою аргументацию разбили, а другой не завезли. Остается, что брать пост на несколько килобайт и найти там противоречия, которые вытекают во основном из того, что ты что-то неправильно понял.>Т.е. ты хочешь сказать что в RPC невозможно загрузить файл в 1 запрос?Я написал, что RPC мощнее ровно в том посте, на который ты ссылаешься. Ты почитай его, там многолетний опыт и выжимка того, что ты по жизни редко встретишь.Суть не в том, что RPC что-то не может, а в том, что RPC слишком мощен. Обрати внимание, что говорят о restful, но не говорят об rpcful. Потому что RPC - это то говно, что получается у любой маньки автоматически. Как есть - вызов процедур издалека. А интернет среда слишком специфическая, чтобы этого было достаточно.
>>1302040>Нет, это не RPC.Пока что ни одна макака ИТТ не смогла объяснить почему вызов процедуры является REST и не является RPC.
>>1302045>Нет, заним... бла-бла-блаВаше мнение очень важно для нас.>ты что-то неправильно понялБолее опытный программист, научись доносить мысли четко, а не мямлить как детсадовец.В общем ты сам путаешься то у тебя за один запрос файл нельзя отправить, то слишком мощен. Обосрался - так и скажи.
>>1302048>В общем ты сам путаешься то у тебя за один запрос файл нельзя отправить, то слишком мощенНу как я и говорю. Аргументы кончились, пошла демагогия в виде доебок, демонстрирующих собственное непонимание. Я ни разу не писал о том, что RPC нельзя отправить файл одним запросом. Я писал о том, что REST как система правил не позволяет тебе наворотить той хуйни, которую можно наворотить с помощью RPC (inb4 а я и на ресте хуйни наворочу). Если ты не видишь разницы, не знаю, попробуй еще раз перечитать.А если у тебя цель доказать анону с борд, что он обосрался, так можешь еще написать, что мамку мою ебал.
>>1302047Любой запрос вызывает процедуру, ты как себе представляешь, HTTP запрос, который ничего не вызывает? Охуенный, наверное, сервер должен быть, сервер, который нихуя не делает.Ты не тот анон, который возмущался тем, что POST модифицирует стейт сервера?
>>1302020>Лишний запрос делать? Круто.Почему ты решил, что он лишний? В этом суть РЕСТ - запрашивай, отвечу.>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: ... }
>>1302058Хуя ты REST-евангелист. Чем это лучше POST /enemy/1?burn ?Только куча лишнего говна, на которое 405 да 410 отвечай
>>1302069>Чем это лучше POST /enemy/1?burn ?Query string обычно используется для уточнения запроса в коллекции. Сортирануть, сделать выборку, вот это всё. Но можно и так, хуле. Тогда семантикой сам наделяй свои УРЛы. Но /enemy/1/burn - это ресурс-действие burn.>>1302069>Только куча лишнего говна, на которое 405 да 410 отвечайВам дали разнообразный инструмент, а вы только 404, да 200 используете. Как купить ламборгини, чтобы иногда в нем посидеть.
>>1301989Значит это не укладывается в твой евангелизм, и ты пытаешься изменить уже сам хттп? Приложуха не задеплоена - 404, все верно
404 значит нет пользователя. А как будет "пользователь уволен"? Или "пользователь ушел в туалет"? Какой код выдумаете?
>>1302075>Но /enemy/1/burn - это ресурс-действие burn.Хм, но ведь по сути burn это на самом деле создание corpse из enemy.То есть надо делать POST /corpse {"enemy_url":enemy/1, "method":"burn"}, который повесит на enemy 302.
>>1302083Если предметная область именно такая, то можно и так. Только код будет 301 всё-таки.>>1302082Всё уже выдумано до тебя. Используй тот код, который семантически ближе к ситуации, например, "ушел в туалет" - 302, а "уволен" - 410.
>>1302088Это не ответ на вопрос. Их добавили в протокол чтобы что? Чтобы служить, как в армии что ли?
>>1302090302 Found, 302 Moved TemporarilyГде тут про туалет? Может все таки не пытаться натянуть сову на глобус?
>>1302053> ты как себе представляешь, HTTP запрос, который ничего не вызывает? Охуенный, наверное, сервер должен быть, сервер, который нихуя не делает.Есть RESTful URL: https://www.w3.org/WAI/ER/tests/xhtml/testfiles/resources/pdf/dummy.pdfОн содержит ресурс dummy.pdf.Ты можешь с ним выполнять любые HTTP-действия и ни одна процедура не вызовется. Круто?
>>1302094Если тебе не нравятся существующие коды, ты можешь добавить код 433 Resurs syebalsa v tualet. Протокол это позволяет, читай пункт 6.1.1 RFC 2616.Ты думаешь, что был вот такой HTTP, а потом пришли хипстеры и придумали какой-то там REST, пытаются натянуть что-то там и так далее. А все наоборот. Был продуманный протокол HTTP, придуманный умными мужиками, которые представляли, как интернет должен выглядеть. Все эти практики обозвали умным словом REST. И HTTP по дизайному своему предусматривает На, почитайhttp://www.peej.co.uk/articles/rest.htmlhttps://www.w3.org/TR/2002/WD-webarch-20020830/https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htmТы в 2002 родился хотя бы?А потом пришел кровавый энтерпрайз со своим RPC.
>>1302104>А потом пришел кровавый энтерпрайз со своим RPC.Маня, в кровавом энтерпрайзе все это было пройдено еще лет 30 назад. Смешно наблюдать, как вы изобретаете wsdl и транзакции
>>1302105Энтерпрайз способен только создавать убогое распильное bloatware и ничего изобрести не может. Именно поэтому интернет основан на TCP/IP, а не ебучих монстроидальных протоколах телекомовых монстров.
>>1302058>Почему ты решил, что он лишний?Потому что без него можно обойтись.>POST /enemy/1/burn может создавать, например /ashes/1Может. Но если он что-то и создает, как минимум GET /enemy/1/burn должен быть доступен, т.к. создается именно /enemy/1/burn.>Если создается новый ресурс, то только POSTИдемпонтентные запросы выполняются с помощью PUT. Сколько ни отправляй запрос на создавание /enemy/1/burn, он может существовать только в одном экземпляре, а значит запросы идемпотентны. PUT.>Это все не нужно, так как не соответствует предметной области.Это и есть противоречие. Для предметной не нужно, для REST нужно (есть и другие способы соблюсти РЕСТ конечно).>>1302058>OPTIONS /enemy/1/collect_ash>Ответит тебе на твой вопрос.На вопрос ответить должен аффтар.
>>1302101>Ты можешь с ним выполнять любые HTTP-действия и ни одна процедура не вызовется.Ага, блядь, а файл на мой компьютер святым духом попал, а не в результате http-запроса. Ты наркоман какой-то, то ЗАПРОСЫ не вызывают процедур, то REST у тебя не может менять ресурс, потому что "ну че вы не поправилам играите, я же придумал, что так не может быть, значит так быть не может".
>>1302108>Потому что без него можно обойтись.Ну обойдись, если хочешь.>Может. Но если он что-то и создает, как минимум GET /enemy/1/burn должен быть доступен, т.к. создается именно /enemy/1/burn.Создается то, что указано в ответе в Location, а не в твоей фантазии.>Сколько ни отправляй запрос на создавание /enemy/1/burnОн уже создан давно вместе с enemy. И на него можно послать только один POST запрос.>для REST нужноНе нужно.>На вопрос ответить должен аффтар.Например OPTIONS /enemy/1/collect_ash вернетAllowed: POST
>>1302121>Ну обойдись, если хочешь.Ну так хули спрашивал чего он лишний.>Создается то, что указано в ответе в Location, а не в твоей фантазии.Создается то, что указано в URI, а не твои фантазии.>>Сколько ни отправляй запрос на создавание /enemy/1/burn>Он уже создан давно вместе с enemy.Он никогда не создан потому что это вообще не ресурс.>И на него можно послать только один POST запрос.То что ты игнорируешь идемпотентность этого действия, не делает POST уместным. Rule of thumb: POST создает сущности, URI которых неизвестен, PUT создает сущности, URI которых известен. Тут URI только один. Следовательно PUT.>Не нужно.Oh wow, да у нас тут аргумент "яскозал".>>1302121>>На вопрос ответить должен аффтар.>Например OPTIONS /enemy/1/collect_ash вернет>Allowed: POSTТолько тут ничего не создается, следовательно POST не катит.
>>1302118Ты выполнил HTTP-действие GET и получил файл. Ты обратился к RESTful ресурсу. Никакого программного кода за http-сервером даже не запускалось. Беги к врачу, вставляй свечу.>REST у тебя не может менять ресурс, потому что "ну че вы не поправилам играите, я же придумал, что так не может быть, значит так быть не может".Не пизди, не говорил я такого.
>>1302126>Ну так хули спрашивал чего он лишний.Но ты даже не пояснил как без него можно обойтись, а мне лень у тебя спрашивать дальше.>Создается то, что указано в URI, а не твои фантазии.>Он никогда не создан потому что это вообще не ресурс.Ой всё.>Oh wow, да у нас тут аргумент "яскозал".Как и у тебя твой.
>>1302128>Никакого программного кода за http-сервером даже не запускалось.А, то есть у нас http-сервер на святом духе работает.
>>1302132>Oh wow, да у нас тут аргумент "яскозал".А у тебя аргумент "я нагуглил это пять минут назад на stackoverflow".Почитай RFC и кончай троллить тупостью. Твой пост полная хуйня. Полнейшая.При желании можно доебаться до того, что /ashes/1 не является подурлом /enemy/1/burn, но там используется слово usually, и в новом rfc это уточнили. И это все.
>>1302148Лооол. Макака, ты чего на личности перекатиться решил? Напиши "полнейшая" еще 3 раза, может тогда это будет звучать убедительней.
>>1302132Твоя аргументация сводится к "ваш ресурс не ресурс, а мой ресурс - ресурс". Ты слишком долго был в ООП. Тебя не вылечить.
>>1302163Дебил, это не аргументация, а тезис. Разве виноват я что чмони типа тебя не понимают разницы между созданием ресурса и вызовом процедуры.
>>1302169Имбецил, тезисы, по крайней мере в логике, требуют доказательств. Если у тебя какие-то другие тезисы, то они никому тут нахуй не нужны.
>>1302181Вся твоя аргументация сводилась к "смотрите че по ссылке написано", а на поверку оказалось, что написано там то, что говорили тебе. А значит ты либо читать не умеешь, либо ты глупенький упёртый баран. Первое что вряд ли, посты анонов ты всё же как-то умудряешься прочесть.
>>1302197Неразумные дети, матчасти не знающие, меня спрашивали ссылку какую-нибудь. Я давал. Они там что-то находили что им нравилось, фантазировали под воздействием синдрома утенка. А тем временем ни одна тупая макака, которая тонну говна написала с переходом на личности, не смогла отличить создание ресурса от вызова процедуры.
>>1302157Я прямо написал, что твои слова противоречат rfc. Если ты этого не понял... впрочем, не похоже, чтобы ты вообще что-то понимал
>>1302205Маня, тут никто не будет у тебя выпрашивать рассказать какие слова, какое rfc, какое противоречие. Не умеешь излагать - иди нахуй.
>>1302197Ыыы, так оп еще и сам эту ссылку принес? Лол. А я возмущаюсь, что он rfc не читал. А он в туториале для самых маленьких запутался
>>1302203>создание ресурса от вызова процедуры.Процедура - это тоже ресурс, и POST на этот ресурс - это вызов процедуры. И этот вызов не обязательно ломает ограничения REST.
>>1302215И? По этой ссылке есть разные мнения. Утята умеют только одно воспринимать - которое первым увидели.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.
>>1302219Процедура - часть бизнес-логики. Ресурс - часть бизнес-данных.Как это не может дойти необучаемым, я не понимаю.Ресурс может вообще в отрыве от бизнес-логики существовать. Файлы в папочке.
>>1302222Ресурсом может быть любая сущность, в том числе и процедура.Как это не может дойти необучаемым, я не понимаю.А не любитель ли ты MVC, часом?
>>1302221>И? По этой ссылке есть разные мнения. Утята умеют только одно воспринимать - которое первым увидели.А, то есть аргументом является мнение некоторого Шона в комментариях к статье, на которую ты сослался.Не ты с Шоном долбоебы, а все остальные, включая админа того ресурса. Ооок.На самом деле даже наличие большого и длинного туториала не доказывает ничего о точке зрения, ведь всегда есть вероятность, что автор туториала долбоеб. Но очень забавно, что ты сам принес ссылку на статью, которую прочитал жопой и был уверен, что она подтверждет твои слова, а теперь тебе приходится маневрировать, отыскав коммент анонимуса.>>1302209Мм, нет. Ты привел серию утверждений без доказательств:- Создается то, что указано в 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 которой неизвестен.
>>1302354Ох блядь, а не подскажешь, что нужно почитать, чтобы обосновать следующий высер:>То что ты игнорируешь идемпотентность этого действия, не делает POST уместным. Rule of thumb: POST создает сущности, URI которых неизвестен, PUT создает сущности, URI которых известен. Тут URI только один. Следовательно PUT.У меня уже моча кончилась обоссывать тебя.
>>1302363Утёнок, а у тебя есть собственные мозги чтобы думать, или тебе на всё нужна ссылка на авторитет?
>>1302354У тебя какая-то каша в голове, анон. Ты путаешь протокол HTTP и архитектурный стиль REST.У тебя какой-то свой HTTP, отличный от RFC 7231, и какой-то свой REST, отличный от описанного в диссере http://roy.gbiv.com/pubs/dissertation/top.htm . RFC 7231 так же ссылается на этот диссер.>>1302378>Утёнок, а у тебя есть собственные мозги чтобы думать, или тебе на всё нужна ссылка на авторитет?Ой, кто тут у нас? А у нас тут Кулибин, ёпта. RFC - это не авторитет, это, стандарт, т.е. соглашение между разработчиками. Если ты его не придерживаешься, то это твои личные проблемы. Хочешь поменять стандарт? Пиздуй в IETF доказывать свое очень важное мнение и, возможно, тебя услышат.
>>1302386Т.е. мозгов у тупого утёнка всё-таки нет. Размышлять, аргументировать - не твоё. Тебе нужно указание от барина.Ну держи, уёба, - https://tools.ietf.org/html/rfc7231#section-4.2.2
>>1302390Самоделкин, никому не нужно твоё неправильное мнение. Ты в ОП посте спросил что не так с REST, тебе всем двачем показали, что ты не знаком со стандартом, а с RESTом всё в порядке. Если ты хочешь дальше высказывать свое некомпетентное мнение и не пользоваться общепринятым протоколом HTTP, а выдумывать свой, то и не жалуйся, что твой выдуманный РЕСТ не натягивается на твоё ООП.
>>1302396Чмоня, отучайся говорить за всех. Я тебе дал бумажку от твоего барина с подтверждением моих слов, теперь пожри говна и больше не выёбывайся на взрослых дядь.
>>1302378>Утёнок, а у тебя есть собственные мозги чтобы думать, или тебе на всё нужна ссылка на авторитет? Я пытаюсь тебя заставить думать. В посте >>1302126 на который я отвечаю >>1302227 ни слова о REST нет. Там исключительно высер о том, что, оказывается "/enemy/1/burn - не ресурс" и прочие охуительные истории. Если ты пишешь ">REST/>RFC для HTTP", то это очередной случай твоей дислексии, потому что обоссан ты был за чушь по поводу HTTP.
>>1302401> ни слова о REST нетА тред называется "REST vs OOP". Следовательно твой высер нерелевантен.
>>1302402Нет, это твой высер >>1302126 нерелевантен. Ты там доебался до человека, что он использовал не тот HTTP-запрос. Доебался неверно, конечно же (там нужен POST-запрос ответом 201 и полем location, как он и написал), но я уже не помню, чтобы не обосрался хоть в чем-то.Я еще вчера написал, что по основной теме тебя обоссали еще вчера, и ты трепыхаешься, пытаясь в демагогию. Получается плохо, так как в демагогию ты можешь как и во все остальное.
>>1302409С тобой действительно про это никто не спорил. И тебе сейчас три человека на это указывают. В посте, на который ты ссылаешься, этого нет. Напоминаю, что ты умственный инвалид, который в айти никогда не добьется успеха, потому что так нельзя.
>>1302409По семантике, которую заложил в АПИ я, запрос на ресурс /enemy/1/burn должен создавать ресурс в коллекции /ashes/ , а ресурс enemy/1/burn удаляться.Ты с какого-то хуя начал твердить, что запрос на /enemy/1/burn должен создавать ресурс по этому же УРЛу. В таком случае, бесспорно, должен быть PUT.Я тебе просто пытался донести ту семантику, которую в этот запрос вложил я. И вдруг ты решил, что я с тобой спорил про идемпотентность, лол. Ну не дебил ли ты сам?
>>1302416Еблан, запрос на ресурс в РЕСТ включает в себя verb, когда ты запрос на ресурс обозначаешь одним только URI, это лишний раз показывает что оно не является ресурсом. Это RPC.
>>1302425Ты тупой, чтоле?POST /enemy/1/burnverb в URI (burn), метод POST - т.к. операция над этим ресурсом не идемпотентная (создает /ahes/1 и вешает на burn 510), остальные методы на burn возвращают 405.Хули тебе тут не понятно? Не нравится, что verb в URI, а одноразовый ресурс burn был создан при создании ресурса /enemy/1? Так можешь пройти нахуй, ни стиль REST, ни протокол HTTP не накладывают ограничений на это. И при этом АПИ вполне соответствует предметной области.
>>1302655Тыщу раз объяснил в треде. Начиная с ОП-поста. Ни один из тех, кто не согласен, не может объяснить в чем разница между REST и RPC и называет РЕСТом всё на свете, даже небо, даже Аллаха на основании того, что в URI есть слово resource.Единстенный кто попытался объяснить разницу, сказал что разницы не знает нет >>1301727. Остальные даже не пробовали ответить.
>>1302673Так тебя смущает наличие глагола в URI? В REST на это ограничения нет, что я тебе тыщу раз в этом треде говорил, но ты так и не привел ни одной цитаты ни из диссера, ни из какого-нибудь rfc, подтверждающего твою правоту. При этом ты упорно продолжаешь твердить своё, ссылаясь на какого-то рандомного хуя из интернетов. И этот хуй всего-лишь оставил комментарий к статье, в которой даже сам автор допускает глаголы в URI.
>>1302693Меня смущает что ни один долбоёб включая тебя не понимает разницу между REST и RPC. Я блядь открытым текстом это пишу который раз.
>>1302740Мало обоссали? Вот тебе еще урины, даунёнок: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.
>>1302748Когда сделаешь тот же пример с burn/dismember/kill на RPC и сможешь объяснить в чем разница с твоим "REST", тогда поговорим.А пока, даунёнок, не плюйся, а держи урину в своём рту.
>>1302749Принимай урину дальше, дебил.Например, JSON-RPC (транспортный протокол не важен)Запрос: {"id": 1, "method": "kill", "params": {"enemy": 1}}Ответ: {"id":1, "result": "killed"}И подобные запрос-ответы.Как видишь, никаких ресурсов не создается (а их и нет в терминологии рпц, лол), АПИ известен двум сторонам заранее, всё это неюниформно, т.е. у каждого сервиса своё. И все это в отличие от REST, где есть одна входная точка в сервис, а дальше по ссылочкам, ходишь по ресурсам, которые динамичны, юниформны, самоописуемы, и предоставляют новые ссылки. Красота.За остальной порцией урины снова пройди в википедию, в rfc и в диссер филдинга.
>>1302877>Ресурс - значит это REST.Пиздуй читать про REST. И пока от зубов не будут отскакивать все ограничения, накладываемые на сервис, не смей тут даже кукарекать.
>>1302888Долбоёб, это тебе надо читать, потому что это ты выше доказывал что URI=РЕСУРС с точки зрения РЕСТ.
>>1302893Мудак чтоле? URI - это ресурс (адрес, имя ресурса, как хочешь называй) в HTTP. REST тут каким боком вылез?
>>1302889Ну и что дальше? Из того, что точка входа в JSON-RPC - это ресурс по адресу / не следует ничего из того, что ты пытаешься доказать. Тут никто не утверждал, что у RPC нельзя HTTP использовать как транспорт
>>1302897Выше по треду маня доказывала что `/enemy/1/burn` - это РЕСТ, поскольку наличие ресурса соблюдено, поскольку есть URI, и похуй что обращение к процедуре.Ну так и здесь есть URI, я жду когда маньки смогут объяснить в чем же сакральное различие. Такая же неконсистентная неюниформная параша с протоколом че когда вызывать можно.
>>1302904Ну ты тупооой. Ресурс не может быть REST. Ресурс может быть RESTful, если он соблюдает ограничения REST. Я тебе весь тред об этом твержу, но ты, еблан, похоже жопой читаешь.И ты так и не показал какое именно ограничение REST нарушает ресурс-контроллер (процедура, функция, как хочешь назови), а всё маняврируешь со своим ебаным рпц.>Такая же неконсистентная неюниформная парашаДокажи
>>1302904>Выше по треду маня доказывала что `/enemy/1/burn` - это РЕСТЭто уже наверное десятый раз в треде, когда ты доказываешь, что ты не умеешь читать. Был диалог""">>Сколько ни отправляй запрос на создавание /enemy/1/burn>Он уже создан давно вместе с enemy.Он никогда не создан потому что это вообще не ресурс."""В котором тебя обоссали, так как - /enemy/1/burn - это ресурс, по определнию. Даже твоя мамка может быть ресурсом, если выдать есть URI.Дальше ты врубаешь логику, мол, а "/" тоже ресурс, а ЗНАЧИТ У ВАС ПРОТИВОРЕЧИЕ. Только вот противоречия нет. Оно в твоей тупой башке. Из того, что твоя мамка - ресурс, не следует, что она часть restful API. А вот если окажется, что она подчиняется определенным правилам, то тогда да.
>>1302926>/enemy/1/burnТ.е. это ресурс, но не restful API?>>1302917>>Такая же неконсистентная неюниформная параша>ДокажиПридумал для enemy неюниформный экшен burn (и кучу других) просто потому, что захотел. У других сущностей его нет. Правил по которым такие экшены создаются тоже нет, кроме желания твоей левой пятки. Хуй положил на консистентность.После первого вызова `POST ../burn` все последующие будут возвращать ошибку - надо соблюдать протокол что зачем вызывать.>>1302917>И ты так и не показал какое именно ограничение REST нарушает ресурс-контроллер (процедура, функция, как хочешь назови), а всё маняврируешь со своим ебаным рпц.Я всё показал тысячу раз, если у тебя мозгов не хватает стол от стула отличить, кто тебе доктор.
>>1302947>неюниформныйЭтот ресурс запрашивается методом POST. А значит юниформный.>У других сущностей его нет.Это ограничение REST?>Правил по которым такие экшены создаются тоже нетЭто ограничение REST?>Хуй положил на консистентностьА вот тут подробнее давай. Где же тут неконсистентность-то зарылась?>После первого вызова `POST ../burn` все последующие будут возвращать ошибкуВот этого я от тебя и ждал, лол. Ну не долбоёб же ты? Вот тебе пример попроще: после вызова, скажем, DELETE /collection, POST /collection {newitem: ...} будет возвращать ошибку. Тоже не REST?>надо соблюдать протокол что зачем вызывать.Не надо никаких протоколов. Ресурс сам тебе расскажет что с ним можно делать, а что нельзя.
>>1302947>Я всё показал тысячу раз, если у тебя мозгов не хватает стол от стула отличить, кто тебе доктор.Ты выдумал свой REST
>>1302963>>неюниформный>Этот ресурс запрашивается методом POST. А значит юниформный.Лол. В огороде бузина, значит в Киеве дядька.>>У других сущностей его нет.>Это ограничение REST?Это неюниформность.>>Правил по которым такие экшены создаются тоже нет>Это ограничение REST?Это неюниформность.>>Хуй положил на консистентность>А вот тут подробнее давай. Где же тут неконсистентность-то зарылась?Повсеместно.>>После первого вызова `POST ../burn` все последующие будут возвращать ошибку>Вот этого я от тебя и ждал, лол. Ну не долбоёб же ты? Вот тебе пример попроще: после вызова, скажем, DELETE /collection, POST /collection {newitem: ...} будет возвращать ошибку. Тоже не REST?Это REST. И это отсутствие ресурса, который был удален. Только ты не DELETE используешь и не удаляешь.>>надо соблюдать протокол что зачем вызывать.>Не надо никаких протоколов. Ресурс сам тебе расскажет что с ним можно делать, а что нельзя.В том числе, что можно вызвать kill, затем burn, но не наоборот? И что kill и burn можно вызывать по одному разу только?
>>1302979У тебя свое определение юниформности. Проблема в том, что это не политические споры, определения у всех одни и те же.А именно такое: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 - аналогично.
>>1302999>Вызвав kill ресурс тебе скажет, что burn вызывать уже нельзя. Вызвав burn - аналогично.>надо соблюдать протокол что зачем вызывать.
>>1302999>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 вообще неважен, т.к. у процедуры всего одна операция - вызов.
>>1303005>Делаешь 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 неидемпотентно.
>>1302979>Лол. В огороде бузина, значит в Киеве дядька.>неюниформностьЗначение униформности в 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 можно вызывать по одному разу только?А кого это ебёт, сколько раз можно? Ресурс есть - вернется представление, ресурса нет - вернется ошибка
>>1303016>POST /enemy/1/kill не обязан создаватьДолбоёб, где твоя жопа увидела увидела в моём сообщении слово ОБЯЗАН.>>1303016>Для restfulness важно, GET не меняет стейт ресурса, PUT меняет идемпотентно, POST неидемпотентно.Так НЕ ОБЯЗАН же. Ты только что отказался поддерживать конвенцию. а может вообще ничего не создавать
>>1303019>Долбоёб, где твоя жопа увидела увидела в моём сообщении слово ОБЯЗАН.Мы обсуждаем вписывается ли API анона в REST. Ты говоришь, что ты делаешь POST чтобы создать ресурс, а эта скотина возвращает тебе moved permanently и адрес праха трупа (мол, опоздал, чувак) и называешь это "твоей левой пятке захотелось".Так вот, это желание левой пятки полностью вписывается в REST.>Так НЕ ОБЯЗАН же. Ты только что отказался поддерживать конвенцию. а может вообще ничего не создаватьКакую конвенцию, твой маня-рест, который ты сам придумал? Тебя уже автор REST обоссывает, лалка.
>>1303018>Значение униформности в REST знаешь?Выше пояснил проблемы.>Слив защитан.Анус себе защитай, пёс.>браузеры тоже в DELETE/PUT/PATCH не умеет до сих порТы чё, ебанутый?>однако всё это делают при помощи POSTКостыль ныне не нужный.>А кого ебёт последовательность?Клиента.> И не факт, что эти ресурсы всё ещё будут существовать когда ты сделаешь свой первый запрос на один из них: например, другой пользователь уже сделал burnУ тупых макак удаление ресурса не через rest-action delete, а через вызов процедуры burn.>А кого это ебёт, сколько раз можно? Ресурс есть - вернется представление, ресурса нет - вернется ошибкаКлиента. Если ресурса нет, то и вопроса нет, только как выяснили выше ты и удаляешь ресурсы как макака.
>>1303023Конвенцию того, что делая запрос POST /enemy/1/burn, ты намереваешься создать ресурс с URI /enemy/1/burn, над которым можно делать стандартные http операции.Так-то ты можешь дилдаком себя в срачельник оттарабанить и кукарекать что это не нарушает рест, ведь и правда не нарушает.
>>1303025>Конвенцию того, что делая запрос POST /enemy/1/burn, ты намереваешься создать ресурс с URI /enemy/1/burn, над которым можно делать стандартные http операции.Лалка, такой конвенции НЕТ. Конвенциональный метод для создания ресурса ПО ТОМУ ЖЕ АДРЕСУ - PUT.POST НЕ используется для этого.Какой же ты тупой.
>>1302963>Этот ресурс запрашивается методом POST>>1303029>POST НЕ используется для этого.Какой же ты тупой.
>>1303036Где в процитированном тобой сообщении слово "создается", в твоем маня-мирке опять? Опять жопой читаешь? Опять хочешь обоссывания?
>>1303024>Выше пояснил проблемы.Твои пояснения никак не соотносятся с определением униформности>Анус себе защитай, пёс.Мемасики пошли у мартышки, отлично. А за консистентность так и не пояснил.>Ты чё, ебанутый?Нет ты.>Костыль ныне не нужный.Ты скозал?>>1303024>rest-action deleteЧмоня, ты до сих пор путаешь REST и HTTP, хотя по этому поводу тебя уже обоссали и не раз.>Клиента.В представленном АПИ клиенту похуй. Ему дали урл, а что там по урлу он узнает только сходив по нему - это и есть суть HTTP протокола, дебил.
>>1303038Правильно, макакам нахуй не нужны конвенции, макака будет использовать POST для .... сама не знает для чего, на то она и макака.
>>1303085>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).Этого на скрин, конечно же, не влезло по идеологическим причинам.
>>1303095Не думаю. Он скорее всего очень хуево знает английский и обладает богатой фантазией.Не замечая при этом, что, например, в табличке GET повторяется два раза, а про PUT не сказано, что он может создавать ресурс. То есть это табличка с примерами типичных действий, заведомо неполная.Меня каждый раз порывает написать "и че, ссылаешься на какого-то блогера, а может он долбоеб", но каждый раз оказывается, что написано там в общем-то верно, а опушка очередной раз прочитал жопой.
>>1303095Да, совершенно верно. Есть пидарасы типа тебя, которые делают левую хуйню, и называют её РЕСТ, хотя она не отвечает 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 - это interactionFAIL
>>1303100GET там зачем-то для двух типов ресурсов запилили, как будто коллекция чем-то принципиально отличается от элемента коллекции.
>>1303117Опять жопой читаешь. Я привел эту цитату, т.к. ты выдумал какую-то конвенцию, которой нет и в помине.>/enemy/1/kill - это interactionЭто точно такой же identification, единый и не делимый. Kill - это подресурс, а Interaction в данном случае POST. Обращение к этим ресурсам возвращают их полные представления и нет никакого протокола взаимодействия поверх HTTP.Филдинг говорит совершенно о другом: нехуй запиливать протоколы, т.е. делать что-то, что необходимо знать помимо представления ресурса. И этим занимаешься именно ты. У тебя, блять, rest-method delete, put-хуют, именно ты считаешь HTTP методы неотъемлемой частью REST, ты выдумал какую-то последовательность действий для моего примера и требования знания клиентом об одноразовости ресурсов.В моем примере клиенту достаточно знать только то, что есть в представлении и это есть RESTful. О чем я тебе твержу тут уже полтреда, но ты упоролся в рпц.
>>1303117И мощнейшая порция урины от самого Филдинга (из комментариев к статье):>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.
>>1302999>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 никуда не денутся.
>>1303151Ну не тебе толковать Филдинга. Он написал что написал.Можешь найти 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` в разное время было сказано:>>1302227>POST запрос может как несоздавать что-то и вернуть 200, или создавать и вернуть 20х, при этом адрес ресурса возвращается в поле Location>>1302405>там нужен POST-запрос ответом 201 и полем location, как он и написал>>1303151>Обращение к этим ресурсам возвращают их полные представленияКое-кто тут запизделся.
>>1303496>А вот enemies никуда не денутся. Ты скозал?Ты хочешь, чтобы глаголы куда-то девались, а существительные нет, но это исключительно твое желание, чтобы пропихнуть свою демагогию. Деться может что угодно, важно то, как сообщить об этом клиенту. В случае RPC у тебя нет универсального способа, а в случае REST ты получаешь список контроллеров с помощью GET /enemy/1/, в которой будет список гиперссылок на методы enemy. Это и есть то, о чем говорит английский текст и выше писалось.>>1303501>Ну не тебе толковать Филдинга. Он написал что написал.В случае вашего общения ты должен смотреть в рот этому толкователю, потому что у вас очень разный уровень. Ты не самый умный человек на свете, прикинь. Ты даже на этой доске не в топе 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, а не гиперссылки.>Кое-кто тут запизделся.Или ты опять обосрался с пониманием. Ты обращай внимания на модельные глаголы, как "может", "нужен", на время глагола и прочие вещи. И тебе откроются знания, которые тебе пытаются донести, а не собственные фантазии.
>>1303514Не я скозал, а это очевидно. Да ты и против ничего не высказал по сути.Правда, в самом слове enemy есть логика противоборства, поэтому лучше заменить его на player. Заодно это избавит от ситуации, когда каждый участник не может получить enemy с собственным id (ведь сам себе врагом быть не можешь).>В случае вашего общения ты должен смотреть в рот этому толкователю, потому что у вас очень разный уровеньТвой километровый высер дальше читать нет сил от смеха.
>>1303528>Не я скозал, а это очевидно.Нет, ты сказал. Потому что очевидно другое: твои слова о версионности можно применить к любому REST-апи. "А что, если ресурс пропадет, ошибка что ли будет". Да, будет.>Да ты и против ничего не высказал по сути.Да как-то похуй. Нормальный человек спорит прежде всего с собой. Ты же споришь с другими в расчете на то, что твоя демагогия прокатит. А она не прокатывает, так как собеседники у тебя как раз спорят не с тобой - они ищут истину.>Правда, в самом слове enemy есть логика противоборства, поэтому лучше заменить его на player. Заодно это избавит от ситуации, когда каждый участник не может получить enemy с собственным id (ведь сам себе врагом быть не можешь).И вот ты вернулся в свою уютную гуманитарную хуйню про игоры. Это совсем не интересно, какое там слово. Суть твоей претензии в том, что в REST не может быть глаголов, и тебя обоссали уже с цитатой автора этого термина.>Твой километровый высер дальше читать нет сил от смеха. От батхерта у тебя нет сил читать, у тебя всегда бомбит, когда я говорю, что ты не самый умный здесь.
>>1303543> Потому что очевидно другое: твои слова о версионности можно применить к любому REST-апиМои слова были о application specific URI structure, а не версионности. Иди дальше истину ищи, искатель.
>>1303551Я уже все нашел (лично я не понимал важность гиперссылок в rest, анон обратил внимания и теперь я тоже вижу что в тех rest api, везде ссылки), второй день захожу в тред только пописюнькать на тебя. О "application specific URI structure" ты тоже нихуя не понял, как водится.
>>1303501>Включаем логику. У чего угодно в вебе есть 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, разве не очевидно? Если представление ресурса - это факт создания ресурса, то тебе это и возвращается.
>>1303564>Но с /enemy/1/kill совершенно другая ситуацияС этого места пошло твоё личное мнение, оно не выглядит обоснованным.>если POST /enemy/1/kill сводится к PUT /enemy/1 {status: killed}Что значит "сводится"?>а значит URI /enemy/1/kill не может не существоватьИз чего значит? Абзац без смысла.>представление ресурса - это факт создания ресурсаКак может факт создания быть ресурсом? Ресурсом может быть информация о создании, к который ты сможешь раз за разом обращаться. Может быть сущность, к которой ты опять же можешь обращаться. У ФАКТА СОЗДАНИЯ может быть URI вообще?Если метод POST означает создание ресурса, а ресурсом является факт создания ресурса, получается запрос POST /enemy/1/kill создает факт создания ресурса. И с этим ресурсом нельзя сделать ничего. Странный "ресурс".
>>1303575>>представление ресурса - это факт создания ресурса>Как может факт создания быть ресурсом?Не ресурсом, а представлением ресурса. Смотрю в книгу - вижу фигу. § 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-заголовком? Да, является.Такой сложный абстрактный тремин нужен, потому что сказать "файл", "документ" и т. д. слишком конкретно.
>>1303579Последовательность байтов - это представление ресурса. Ну а ресурс-то какой? Что ты создаешь делая этот ПОСТ? Создаешь факт создания?
>>1303575>С этого места пошло твоё личное мнение, оно не выглядит обоснованным.Какое тебе, нахуй, обоснование? С этого места я объяснил тебе как устроен ресурсне надо было, что у него есть URI, что URI и взаимодействие с ним не нарушает HTTP, и он соответствует REST но ты опять нихуя не понял.>Что значит "сводится"?Это значит, что нет разницы между POST /enemy/1/kill и PUT /enemy/1 {status: killed}>Из чего значит? Абзац без смысла.Из внешней документации.>Как может факт создания быть ресурсом?Раз уж так придираешься к словам, то все как ты сказал. Кроме одного. Информация о создании - это представление ресурса, а не сам ресурс.
>>1303588>Ну а ресурс-то какой?Какая нахуй разница? У тебя есть представление ресурса, вот из него и получай всю информацию о ресурсе, об этом тебе говорит REST.
>>1303588>Ну а ресурс-то какой"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/. Но пост не всегда означает создание ресурса. Как и пут. Хотя в данном случае это так.
>>1303594>Можно написать <a href="/enemy/1/kill">убить супостата</a>? Можно. Значит это ресурс.Естественно html не поддерживает POST запросы таким образом, но это уже ограничение HTML
>>1303606Это называется способность к абстрагированию. В чем лично твоя не макачность заключается? Дохуя проектов поднял?
>>1303606Дурачок, чтоле? Клиенту вернулось представление ресурса. Ну как его может ебсти, что за этим представлением скрываются 10 файлов на диске и 100 рекородов в БД? Если клиента ебёт и он должен знать, что там именно 10 файлов, а не 10 ответов с 10 сторонних серверов, то у сервиса неправильный АПИ.
>>1303608Это называется способность лепить говно.>В чем лично твоя не макачность заключается? Дохуя проектов поднял?А это называется переход на личности. Типичный приём макаки.
>>1303610>Это называется способность лепить говно.Нет. Ты просто не программист и тебе не понять.>А это называется переход на личности. Типичный приём макаки. Так это ты написал "Тащем-та вся суть макак" и перевел все в эту плоскость. А личность у тебя лузера, прямо скажем.
>>1303609Дурачок, клиенту надо понимать ЧТО именно ему вернулось, чтобы понимать что с этой сущностью делать.
>>1303617Заклинание написал, а ответа ушел. В чем лично твоя не макачность заключается?Пока ты показал только непонимание русского и английского языка, тупизну и постоянное переспрашивание одного и того же. Может я что-то не знаю, расскажи о себе.
>>1303619Ему вернулось представление ресурса. Это все, что ему надо знать. В этом представлении есть нужные URI, Content-Type, тело сообщения и вся другая необходимая информация. С таким подходом ты допиздишься до того, что даже в невинном RESTful GET /person/op , возвращающем {age:13, height: "150cm", mass: "260kg", color: green } нихуя не понятно, что именно ему вернулось, если он не знает джсона и ангельского, лол.
>>1303642>С таким подходом ты допиздишься до того, что даже в невинном RESTful GET /person/op , возвращающем {age:13, height: "150cm", mass: "260kg", color: green } нихуя не понятно, что именно ему вернулось, если он не знает джсона и ангельского, лол. Конечно нет, представление-то не полное, не указано, что оп тупой уебок
>>1303645>Ты запросил огурец, а тебе вернулся слон.Очевидно, что в этом случае слон является представлением ресурса по URI огурец.
>>1303659>такой логичный АПИТы его предложил.>приправить спагетти-кодомТы его и готовь.Ну вообще теперь понятно, как ты пишешь программы и что у тебя вместо АПИ.
>>1303922Всё же, таки, ты жопой чтец. Запросил kill, получил представление ресурса kill: ответ 201 Created и URI на corpse.Представление corpse ты получишь, если пройдешь по предоставленному УРЛу.
>>1304089Тебе английским языком всё написано, ты вместо чётких формулировок выдумываешь свои толкования, а жопой чтец почему-то я. Как так?Ты похерил decoupling of identification and interaction. Ты HTTP-specific ответ (location header) называешь полным представлением ресурса.Если собственными фантазиями ("на самом деле Филдинг имел ввиду") конкретные формулировки, если ты кладёшь хуй на консистентность интерфейса АПИ, разве могу я это запретить тебе.
>>1304251Ой не пизди. У тебя одни вскукареки, жопочтение Филдинга и вырванные из контекста фразы.На все твои ответы есть ответы выше по треду.>консистентность интерфейса АПИКонсистентность интерфейса? Ты сам понял что сказал, мудак тупой? REST требует униформности, но ты, настолько имбецил, что путаешь эти два разных понятия.
>>1304301Нет у тебя жопочтение. Основанное на толковании мыслей Филдинга лол.Консистетность это в принципе требование любого хорошего дизайна, долбоёб ты тупорылый.
>>1304309Ты из контекста вырываешь его фразы, идиот. Ты русский-то хуёво понимаешь, а уж ангельский так вообще нихуя. Увидел фразочку со знакомыми словами и давай притягивать её за уши к своему высеру.>Консистетность это в принципе требование любого хорошего дизайнаЭтой фразой ты лишь подтвердил свой долбоебизм и непонимание термина.Требование консистентности относится к данным, а не к интерфейсам, ебанат ты тупой. ACID тебе в помощь.
>>1304320Тупой ебанат, узнай что такое консистентность, потом спросишь разрешения кукарекать. Начать можешь с википедии. Вперёд.
>>1304320>Ты из контекста вырываешь его фразы>Требование консистентности относится к даннымВот именно ты не знаешь смысла консистентности вне единственного контекста данных, и в этом меня упрекаешь, ай лолд, ну и долбоёб же ты.
>>1304345Да хули интересного, есть аноны, которые аноны из-за скромности, а есть те, кто сидит анонимно из-за зашкаливающего мудачества, при котором из нормальных мест вышвыривают очень быстро. На бордах таких много, а вони они создают еще больше
