и ракет там нет)

открыл в инкогнито - факт, не то :(

сорян

https://habrahabr.ru/post/251193/

оно?

оно?

Воо, то что нужно, спасибо

так сложно когда подход "все - это ресурс" изначально неправильный и приходится вот так сильно изворачиваться

PATCH нинужен)

так сложно когда подход "все - это ресурс" изначально неправильный и приходится вот так сильно изворачиваться

действие вполне может быть ресурсом

POST rocket/{id}/launch

представь что ты создаешь команду

это глагол

и что?)

и нет, это существительное

launch - запуск

ну приходится каждому действию придумывать ресурс.

бан юзера - тоже существительное?

да

в целом представь себе что ты с приложением взаимодействуешь отправляя туда команды

скажем проблема с тем же patch - если ты туда кусок стэйта пробрасываешь, а не коллекцию операций - то по сути ты теряешь контроль за тем что и как у тебя работает.

а коллекции операций - сложна

но для batch апдейтов в целом норм

скажем проблема с тем же patch - если ты туда кусок стэйта пробрасываешь, а не коллекцию операций - то по сути ты теряешь контроль за тем что и как у тебя работает.

ват? А если ты хочешь поменять статус ордера с checkout на processed будешь весь боди (со всеми заказаами) передавать на PUT?

со всеми айтемами заказа*

ват? А если ты хочешь поменять статус ордера с checkout на processed будешь весь боди (со всеми заказаами) передавать на PUT?

нет, POST /orders/{id}/processed

а вообще - это проигранная битва. Вся идея с ресурсами подразумевает некую инкапсуляцию, что сервер диктует тебе правила взаимодействия с ресурсами. Отсюда и гипермедиа. И если тебе для взаимодействия с ресурсами нужно какие-то правила на клиенте хардкодить - то это уже нарушение этой инкапсуляции и провал всей идеи.

в WEB это работает. Так как все правила на клиент приходят в виде ссылок и форм, что явно диктует что и куда ты можешь послать, и клиент (браузер) ничего не должен заранее знать кроме как уметь в unified interface.

для мобилок - это сложнее так как речь идет о том что бы клиент собирался из ресурсов приходящих с сервера. Это.... мягко скажем сложно

а потому чаще всего мы тупо хардкодим и структуры данных, и протокол взаимодействия (что в каком порядке и как на что реагировать)

а если это все так сложно - то зачем это все для нашей простенькой API?)

нет, POST /orders/{id}/processed

Любой пост должен возвращать ресурс. Какой ресурс вернешь?

Любой пост должен возвращать ресурс. Какой ресурс вернешь?

любой post НЕ должен возвращать ресурс) по спецификации у POST не должно быть тела ответа

POST - это что-то типа команд. Команды по хорошему ничего не должны возвращать (во имя CQS), так как они не гарантируют тебе идемпотентность операции. Но тебе никто не мешает на самом деле вернуть новый стэйт ордера после применения команды. Дабы не доп GET запрос

то есть эдакие трэйд офы и отхождение от спецификации в угоду удобству и уменьшению количества запросов

Ну вот смотри http://www.restapitutorial.com/lessons/httpmethods.html POST Create 201 (Created), 'Location' header with link to /customers/{id} containing new ID. офф документация Я имел ввиду, что тебе на POST (который именно создание ресурса) нужно вернуть ресурс (ссылку, как я дерну его GET)

Все эти придумывания несуществующих в модели ресурсов... занятие кажущееся не совсем правильным. Даже в той статье.

Вот дай мне в конкретном примере с ордером и чекаутом ссылку, которую вернет ПОСТ

Сначала было так Запуск ракеты: POST /missiles/[id]/countries-landed/[country_id]

Запуск ракеты: POST /missiles/[id]/launcher {target: [country_id]}

и можно крайне много вариантов

а на самом деле это глагол!

одна команда

с нужными парамтерами

Ну вот смотри http://www.restapitutorial.com/lessons/httpmethods.html POST Create 201 (Created), 'Location' header with link to /customers/{id} containing new ID. офф документация Я имел ввиду, что тебе на POST (который именно создание ресурса) нужно вернуть ресурс (ссылку, как я дерну его GET)

ну вот ты кинул ссылку на "еще один" ресурс который предполагает свой вижен. В спецификации HTTP все намного проще: > The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either 200 (OK) or 204 (No Content) is the appropriate response status

то есть POST запрос который в ответ вернет тебе 204 без заголовка Location - вполне себе не нарушает спецификацию HTTP

в диссертации же Филдинга на тему REST ничего про `POST должен всегда возвращать URI ресурса" не говорится

а все что другие пишут - это просто "еще один вижен"

много виженов - это наверно то, что в этих рестах раздражает меня больше всего :)

как некая религия и много толкователей

ты можешь ему придерживаться а можешь забить и сделать свой велосипед. И если уж мы говорим о чем-то готовом - проще взять рекомендации мелкософта по реализации API

как некая религия и много толкователей

REST - архитектурный стиль. То есть это совокупность ограничений накладываемых на систему. В целом у тебя никогда не будет соблюдаться unified interface на 100% (ну как, в теории можно, но очень сложно и практического смысла мало) и ты либо закончишь своим протоколом поверх http либо еще чем-то. А то что все остальные берут и пишут свой вижен того как должно http api выглядеть, где http именно как application level протокол а не просто транспортный, ну... имеют право. Некоторые в целом вполне годные штуки пишут.

чем мне graphql например нравится - это то, что реализация не такая жесткая как у SOAP например, и при тебе доступна информация о том как клиент взаимодействует с сервером. И вот этот момент - реально делает этот подход на голову выше всего остального. И они просто отказались от идеи использовать http как application level протокол

он накладывает противоестественное ограничение, что все есть существительное. Тогда как домен почти всегда - это сущности и глаголы.

он накладывает противоестественное ограничение, что все есть существительное. Тогда как домен почти всегда - это сущности и глаголы.

мутации ведь есть

он накладывает противоестественное ограничение, что все есть существительное. Тогда как домен почти всегда - это сущности и глаголы.

у тебя имена ресурсов по сути имена юзкейсов.

ну то есть это что-то чуть выше уровнем чем операция над доменом

да и опять же - у тебя имена классов тоже всегда должны быть существительными, а все это воспринимают как "добавлю суфикс er/or и сделаю из Validate существительное Validator или DnsResolver"

суть ограничения как раз в том что бы ты имена подбирал по сущностям своим

Dns с методом resolve

а это приведет тебя к whole value концептам

позволит уменьшить количество зависимостей и т.д.

то есть ограничение разумное, но слишком бездумно это ограничение применяют

он накладывает противоестественное ограничение, что все есть существительное. Тогда как домен почти всегда - это сущности и глаголы.

а ну и еще - в оригинальной дисертации я не помню что бы были подобные ограничения)

ну вот ты кинул ссылку на "еще один" ресурс который предполагает свой вижен. В спецификации HTTP все намного проще: > The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either 200 (OK) or 204 (No Content) is the appropriate response status

My bad. Я думал, что мы про RESTful говорим.

ERROR: S client not available

My bad. Я думал, что мы про RESTful говорим.

что такое RESTful?)

https://www.drupalwatchdog.com/sites/default/files/images/web/4.1-RESTfulness-tweet.png

Фесор в своей стихие </простите>

Это как-раз тот ресурс, что я скинул. По которому мы с тобой херачили не одну аппу лет пару назад ;)

Это как-раз тот ресурс, что я скинул. По которому мы с тобой херачили не одну аппу лет пару назад ;)

ну и небыло проблем с этими апишками?)

Неа. Давай примеры.

версионизация, сохранение обратной совместимости, трекинг изменений, именование (сложна), статус кодов не хватает

Только давай вот реальные примеры, а не тонны текста "за жизнь" :)

ну это реальные примеры. у меня были жесткие проблемы с версионизацией на последнем проекте, когда мы наэкспоузили лишнего и потом не могли убрать

у меня так же были проблемы с тем что использование статус кодов для кодов ответов сильно ограничивали и в конце концов они начлаи заканчиваться и мы уже начинали приплетать свои)

да и с тех пор как мы с тобой апишки начали писать, я немного загнался по тому что бы разобраться что такое restful и понял что это булшит на постном масле

я не знаю как ты - а я люблю пересматривать свои взгляды на то как делать дела. 4 года назад я апишки через формы делал, и тогда мне казалось что это ок

и сейчас - загоны по restful без вменяемой спецификации по чем загоняться (а такая спецификация есть только по http. все остальное лишь рекомендации) и при наличии тысяч разработчиков которые делают методы в духе POST /users/create я считаю бессмысленными

Версионизация это не про rest (и не про restful). ЧТо бы ты не юзал будет говно. Юзай graphql .... я хз. Статус коды это что-то странное. У тебя должен быть статус код коррелирующий с HTTP а для бизнесс логики это менеджится другими вещами, как у тебя коды закончились... может ты еще 418 юзал? Вообще я тоже не говорю что restful это панацея - но он решает кучу проблем и писать серверную часть согласно restful гораздо легче, чем просто всякое Г гнать без всякой логики.

Версионизация это не про rest (и не про restful). ЧТо бы ты не юзал будет говно. Юзай graphql .... я хз. Статус коды это что-то странное. У тебя должен быть статус код коррелирующий с HTTP а для бизнесс логики это менеджится другими вещами, как у тебя коды закончились... может ты еще 418 юзал? Вообще я тоже не говорю что restful это панацея - но он решает кучу проблем и писать серверную часть согласно restful гораздо легче, чем просто всякое Г гнать без всякой логики.

дай определение слову restful

короч

https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation_2up.pdf

вот оригинальная диссертация

если хочешь почитай

https://pdfs.semanticscholar.org/8926/4aa06b8933f7007f1eec77a49625e6e9fc05.pdf

а вот откуда и зачем Рой придумал свой rest

а вот определить почему термин rest стал таким популярным у меня не получилось

никаких конкретных определений, никаких конкретных стандартов... просто пух и у тебя есть хайповое слово

как SOA или микросервисы

или ООП

вот оригинальная диссертация

ЭЭЭЭЭЭ дисертация чувака философа за 2000г ..... сча бы в 2017 это читать. Мне не интересно откуда rest термин - я вижу рекомендации, которые, пока что, решают мои проблемы. http://www.restapitutorial.com/lessons/httpmethods.html Эти рекомендации называют RESTful (я встречал такое определение). Повторюсь, вещь не описывает все кейсы, но между вариантом писать POST /user/sendemail (и т.п. говно) и вот этим "RESTful" я выбираю второе.

ЭЭЭЭЭЭ дисертация чувака философа за 2000г ..... сча бы в 2017 это читать. Мне не интересно откуда rest термин - я вижу рекомендации, которые, пока что, решают мои проблемы. http://www.restapitutorial.com/lessons/httpmethods.html Эти рекомендации называют RESTful (я встречал такое определение). Повторюсь, вещь не описывает все кейсы, но между вариантом писать POST /user/sendemail (и т.п. говно) и вот этим "RESTful" я выбираю второе.

как будет выглядеть метод API для смены пароля пользователя?)

на вход два поля - старый и новый пароль

PATCH /user/{id}/ password: MY_FUCKIN_PASSWORD new_password: MY_FUCKIN_NEW_PASSWORD

как ты будешь это в коде делать?

у тебя ж выходит будет куча действий на PATCH /user/{id}