например PUT /api/messages/123/likes

ВОпрос тогда можно, а если надо коогда вы дергаете PUT /api/messages/123/likes запустить какой-нить фоновый процесс, отправить скажем сообщение телеграм ботом. Вы эти вызовы в сущности закинете? То есть будете делать то, что не рекомендуется разработчиками доктрины, использовать в сущностях объекты более выского уровня, которые наоборот как раз сами должны оперировать с сущностями?

но это не "настоящая" сущность. это отношение между сущностью и пользователем

GET /api/messages/123/likes вернет тебе список сущностей, нет разве?

ВОпрос тогда можно, а если надо коогда вы дергаете PUT /api/messages/123/likes запустить какой-нить фоновый процесс, отправить скажем сообщение телеграм ботом. Вы эти вызовы в сущности закинете? То есть будете делать то, что не рекомендуется разработчиками доктрины, использовать в сущностях объекты более выского уровня, которые наоборот как раз сами должны оперировать с сущностями?

доменные ивенты

Поэтому я считаю что АПИ-шка не должна работать непоследственно с сущностями - должен быть еще слой бизнес-логики дополнитлеьный

Поэтому я считаю что АПИ-шка не должна работать непоследственно с сущностями - должен быть еще слой бизнес-логики дополнитлеьный

RPC

GET /api/messages/123/likes вернет тебе список сущностей, нет разве?

а это именно так

GET /api/messages/123/likes вернет тебе список сущностей, нет разве?

вернет массив людей. Но ты же не скажешь что like это человек

в целом оно вернет тебе ресурсы

репрезентацию данных

я могу делать всякие разные репрезентации даже не имея таких "сущностей"

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

ты ж не вернешь просто список людей, которые пролайкали? у каждого лайка будет свой идентификатор, что делает его в принципе сущностью

Поэтому я считаю что АПИ-шка не должна работать непоследственно с сущностями - должен быть еще слой бизнес-логики дополнитлеьный

не бизнес логики - адаптеров между http и твоим приложением. И этими адаптерами и являются контроллеры

а сущности там внутри. dao и процедурки или еще чего - это не столь важно.

Так REST у меня или RPC? ))))

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

интересно как много тут людей знают как аббривиатура REST расшифровывается

и какое отношение REST имеет к конечным автоматам

вернет массив людей. Но ты же не скажешь что like это человек

GET /api/v1/peoples/?message=123?like=true :)

Вот и я не понимаю- хотя лет 6 где-то пишу апишки разные и всегда называл их REST, когда это все укладывается в спецификации сваггера.

GET /api/v1/peoples/?message=123?like=true :)

хреново потому что схема ресурса может отличаться

а то что оказывается надо было с Entity работать чтобы называть это REST-ом - впервые узнал. Да правда такой REST не знаю как применять даже в реалльных задачах...

не поверишь, только на прошлой неделе перечитывал :))

интересно как много тут людей знают как аббривиатура REST расшифровывается

не поверишь, только на прошлой неделе перечитывал :))

что именно? википедию? или диссертацию Роя Филдинга?

Кстати говоря про RPC написано: однако, некоторые построены на основе HTTP (что нарушает архитектуру ISO/OSI, так как HTTP изначально не транспортный протокол). https://ru.wikipedia.org/wiki/Удалённый_вызов_процедур

ща вспомню...

все таки википедию...

ну на вики англоязычной во всяком случае было норм написано

русскоязычную не помню

хреново потому что схема ресурса может отличаться

на что и указывает смайл. Вообще должно быть что то вроде GET /api/v2/peoples/like_by_msg/?id=123

на что и указывает смайл. Вообще должно быть что то вроде GET /api/v2/peoples/like_by_msg/?id=123

нет, можно сделать GET /messages/123/likes

потому что повторюсь - это хоть и похожие ресурсы но они разные

если у тебя у лайка есть собственный идентификатор - хоть GET /likes делай

нет, можно сделать GET /messages/123/likes

это зависит от стиля

это зависит от стиля

REST не про урлы, так что пофиг)

https://ru.wikipedia.org/wiki/REST#.D0.A2.D1.80.D0.B5.D0.B1.D0.BE.D0.B2.D0.B0.D0.BD.D0.B8.D1.8F_.D0.BA_.D0.B0.D1.80.D1.85.D0.B8.D1.82.D0.B5.D0.BA.D1.82.D1.83.D1.80.D0.B5_REST Хоть одну строчку мне тут или где-то покажите, почему надо юзать Entity для REST?

удаленный вызов процедур... штука в том что процедуры не должны ничего возвращать)

удаленный вызов процедур... штука в том что процедуры не должны ничего возвращать)

точно так же как ответы на POST/PUT запросы не должны содержать тела

но они у тебя содержат тело?)

или только локейшен на новый ресурс?

у меня нет rest апишек)

)

как бы ты делал array_pop по ресту?) ну и array_replace например

как бы ты делал array_pop по ресту?) ну и array_replace например

а при чем тут рест?

а при чем тут рест?

это на самом деле не к тебе вопрос... это я хотел про еще один "косяк" людей напомнить - стериотип что post для создания и put для обновления

хотя этот момент как раз таки в спеке по http очень даже хорошо прописан

если array_pop еще можно отделаться с DELETE messages/last, то replace работает сразу со всей коллекцией же

если array_pop еще можно отделаться с DELETE messages/last, то replace работает сразу со всей коллекцией же

вооот. DELETE должен гарантировать идемпотентность. array_pop не идемпонетная операция. Следовательно единственная штука которая нам поможет тут это POST. и выбора у тебя как бы и нет)

вооот. DELETE должен гарантировать идемпотентность. array_pop не идемпонетная операция. Следовательно единственная штука которая нам поможет тут это POST. и выбора у тебя как бы и нет)

ок, даже не так. сразу GET /messages и потом DELETE /messages/{lastId}

и если у тебя (предположим) все операции над сущностями не идемпотентны ты закончишь с rpc хочешь ты того или нет. И это будет по rest-у (с оговоркой что нет)

и с реплейсом в принципе так же

ок, даже не так. сразу GET /messages и потом DELETE /messages/{lastId}

и прощай атомарность операции

зато рест

POST /collection/pop

вот rest

это рпц

это рпц

тебе тайну открыть?) все rest апишки это на самом деле rpc

в наших реалиях? да

в наших реалиях? да

вообще, в принципе. У тебя не может быть rest если клиент у тебя не браузер

какая разница кто клиент?

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

какая разница кто клиент?

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

одно из них - Unified Interface

и вот с ним беда

вооот. DELETE должен гарантировать идемпотентность. array_pop не идемпонетная операция. Следовательно единственная штука которая нам поможет тут это POST. и выбора у тебя как бы и нет)

идемпотентный DELETE - что за чушь? где вы эту дрянь взяли. Только GETы идемпотентны.

единственная имплементация REST на сегодняшний день это WWW

у тебя браузеры научились делать DELETE/PUT?

идемпотентный DELETE - что за чушь? где вы эту дрянь взяли. Только GETы идемпотентны.

9.1.2 Idempotent Methods Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request. The methods GET, HEAD, PUT and DELETE share this property. Also, the methods OPTIONS and TRACE SHOULD NOT have side effects, and so are inherently idempotent.

https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

у тебя браузеры научились делать DELETE/PUT?

ну как бы... ты можешь http verb указать в form тэге если хочешь

идея в том что сервер регламентирует клиенту "куда дальше можно". Делается это элементами гипермедиа такие как ссылки, формы и т.д

это то и дает вэбу бесконечный скейлинг

а тебе для твоей мобилки нужен просто rpc

ну как бы... ты можешь http verb указать в form тэге если хочешь

в method? не поддерживается же

в method? не поддерживается же

я даже по другому отвечу - где ты в диссертации филдинга чего про DELETE запросы увидал?)

9.1.2 Idempotent Methods Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request. The methods GET, HEAD, PUT and DELETE share this property. Also, the methods OPTIONS and TRACE SHOULD NOT have side effects, and so are inherently idempotent.

aside from error or expiration issues - очень важная и не умесная оговрка с которой я не согласен. Но по данной трактовке да DELETE таки идемпотентен.

это часть спеки http

и не более

я даже по другому отвечу - где ты в диссертации филдинга чего про DELETE запросы увидал?)

я тебе за веб и формочки говорю

aside from error or expiration issues - очень важная и не умесная оговрка с которой я не согласен. Но по данной трактовке да DELETE таки идемпотентен.

почему не согласен?

скорее всего имелись в веду ошибки сети а не ресурса

я тебе за веб и формочки говорю

то есть ты хочешь мне сказать что формочки не REST?)))

скорее всего имелись в веду ошибки сети а не ресурса

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

единственная имплементация REST на сегодняшний день это WWW

http как бы. а http не ограничен www. ты ж не напрямую по tcp пакетами общаешься, без поддержки всех методов. или юних сокетами, или вообще по фтп заливаешь командочки?

я тебе за веб и формочки говорю

REST это обоснование архитектурного стиля выбранного для WEB. Это единственное назначение этой терминологии.

то есть ты хочешь мне сказать что формочки не REST?)))

формочки поддерживают только GET/POST. может щас и поменялось что-то, но так всегда было

если мы говорим про HTTP API - то тогда все клево

формочки поддерживают только GET/POST. может щас и поменялось что-то, но так всегда было

повторюсь, ты хочешь сказать что WEB это не REST?))

почему не согласен?

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

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

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

повторюсь, ты хочешь сказать что WEB это не REST?))

я говорю что web это не только браузеры

XMLHttpRequest это не совсем браузер

я говорю что web это не только браузеры

http это не только браузеры, а web это только html и браузеры

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

ошибки сети, а не когда ошибка яляется правильным поведением

а rest != http

http это не только браузеры, а web это только html и браузеры

ну вот ты утверждаешь что rest это только веб, т.е хтмл и браузеры

ну вот ты утверждаешь что rest это только веб, т.е хтмл и браузеры

именно так

а все остальное - http api