Это про транспорт, а не про ваше приложение

и приходится язык http переводить на язык бизнеса.

лишнее

и приходится язык http переводить на язык бизнеса.

ну вот да rest это и пытается сделать))

https://b.yasb.exileed.com/telegram/chat/1001071233926

А язык smtp не надо на язык бизнеса переводить или вебсокеты там?

Или amqp

мне правая девушка всегда нравилась больше :) и да. вопрос. GraphQL - это же про выборку данных. т.е. read операции. write там как обычный RPC? или вообще в стандарт не входят?

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

и приходится язык http переводить на язык бизнеса.

о да, язык бизнеса целиком состоит из урлов... эх...

с этой точки зрения RPC намного ближе к тому что ты хочешь)

с этой точки зрения RPC намного ближе к тому что ты хочешь)

Я это знаю

У меня что? Какая плохая точка зрения?

Sergey Protko, [12.12.17 12:32] как будет выглядеть метод API для смены пароля пользователя?) Sergey Protko, [12.12.17 12:32] на вход два поля - старый и новый пароль Борис Беньковский, [12.12.17 12:32] PATCH /user/{id}/ password: MY_FUCKIN_PASSWORD new_password: MY_FUCKIN_NEW_PASSWORD Sergey Protko, [12.12.17 12:32] как ты будешь это в коде делать? Sergey Protko, [12.12.17 12:33] у тебя ж выходит будет куча действий на PATCH /user/{id} Sergey Protko, [12.12.17 12:33] как ты это в коде маршрутизировать будешь? Sergey Protko, [12.12.17 12:33] как будешь проверять что password валиден? Sergey Protko, [12.12.17 12:33] и что мы можем поменять пароль?)

я тут себе для презенташки записал как-то... :)

а хотя он тут просто неправильно рест готовит. ладно.

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

но маршрутизатор то маршрутизирует Request а он не только из url но и body состоит

просто все привыкли (HTTP_METHOD, REGEXP, Controller (или что угодня для обработки маршрута))

а хотя он тут просто неправильно рест готовит. ладно.

он готовит CRUD

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

какое к черту отношение урлы имеют к rest?)

ну то есть у тебя оно накладывает только ограничения что бы ресурсы были cachable

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

все

дальше называй че как хочешь

какое к черту отношение урлы имеют к rest?)

я сейчас говорю о: Борис Беньковский, [12.12.17 12:32] PATCH /user/{id}/ password: MY_FUCKIN_PASSWORD new_password: MY_FUCKIN_NEW_PASSWORD

GET activeAppointments?category=1,2,3foo=bar

и о проблемах это маршрутизировать

вот тебе вполне по rest-у

и о проблемах это маршрутизировать

Боря путает rest и crud

как и многие

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

ну возможно, просто я сколько вижу разговоров за рест

у всех он свой и специфичный

как и mvc

я вот думаю что многие путают. уж очень оно.. толкает

я могу скинуть тебе видос где объясняю свою точку зрения что у тебя нет и никогда не будет rest)

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

согласен, основная проблема это read

и всякие graphql, odata и тд занялись этими вопросами

согласен, основная проблема это read

нет, с read все довольно просто и если у тебя только read то все как раз таки у людей нормально

и на фоне этих проблем rpc не выглядит так плохо

кстати да. главное - это write

глаголы.

глаголы.

UserManager - существительное но бесполезное

или UrlVerifier - существительное но как бы нет

это не важно

PostPublishUseCase $post->publish();

важно то как ты воспринимаешь изменение. Большинство воспринимают изменение как замену стэйта

патчинг объектов и прочий трэш

я на таких примерах пытаюсь обьяснять

я на таких примерах пытаюсь обьяснять

норм

главное когда делаешь апишку понимать что и зачем ты делаешь. Понимаешь ли ты ограничение cachable из rest, про unified interface ограничения и т.д.

если нет - заткнись и пиши код и не выпендривайся

как там в кватновой физике - "заткнись и считай"

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

то разработка гибкая

и хз как получится все потом через год

то что было год назад нормально

я могу скинуть тебе видос где объясняю свою точку зрения что у тебя нет и никогда не будет rest)

можно?

и хз как получится все потом через год

демагогию опять разводишь. Ты никогда не знаешь как оно будет через год. Никогда.

демагогию опять разводишь. Ты никогда не знаешь как оно будет через год. Никогда.

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

демагогию опять разводишь. Ты никогда не знаешь как оно будет через год. Никогда.

Посмеюсь над этой фразой в следующем веке

поэтому у тебя 2 варианта: 1. Оверинжиниринг 2. Бритва оккама, если что потом перепишешь

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

а где все заложенное расширение оверинжиниринг

поэтому у тебя 2 варианта: 1. Оверинжиниринг 2. Бритва оккама, если что потом перепишешь

а кроме окаммы какие еще бритвы знаешь?)

джилет

джилет

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

слышал о хенлоне каком то

но я хз, чукча писатель, не читатель.

поэтому у тебя 2 варианта: 1. Оверинжиниринг 2. Бритва оккама, если что потом перепишешь

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

возможно, возможно они и не правильные

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

согласен, основная проблема это read

так все же - почему основная проблема это read?

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

так все же - почему основная проблема это read?

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

фильтраций, сортировки и тд

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

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

фильтраций, сортировки и тд

занятно что graphql никак не решает эти вопросы)

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

это представление, просто разное представление, что у тебя там дублируется? ты можешь описать это типами без дублирования а значит все хорошо. и не важно graphql у тебя или нет

короч я не вижу никаких проблем со чтением. Есть вопросы, да, нет стандартов, нет серебрянных пуль, просто смирись с этим. Но проблем как бы нет.

а вот запись, изменение стэйта и т.д. в контексте API (что влечет за собой проблемы инвалидации кэша на клиенте например) это реально вопрос.

но если у тебя нет http cache - то у тебя и проблем и ограничений нет)

ну вопрос инвалидации кэша он известен давно

ну вопрос инвалидации кэша он известен давно

опять демагогия. ладно, я все

я могу скинуть тебе видос где объясняю свою точку зрения что у тебя нет и никогда не будет rest)

можно видос?

можно видос?

Присоединяюсь к просьбе

https://www.youtube.com/watch?v=2nELo4fJMNQ - на но это так, шутки ради

Спасибо!

спасибо

основной посыл - rest это архитектурный стиль а не что-то конкретное. И на этом все.

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

Просто левую сзади не видно, и не совсем понятно, действительно ли правая красивее в этих местах)

Просто левую сзади не видно, и не совсем понятно, действительно ли правая красивее в этих местах)

не, это не так работает)