-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Что за мода пошла? REST-like HTML CRUD
- Автор темы Adelf
- Дата начала
AnrDaemon
Продвинутый новичок
ЭКШЕН один на каждое ДЕЙСТВИЕ.
От REST или CRUD не зависит.
Заканчивай подмену понятий.
Ну те. Берем вебсервис с передачей средствами soap что на самом деле ничто другое как rpc и пишем по экшину на каждый сервис? Типа просто модель передать сложно?
Ну просто пропирало высказаться
И ты. Ворпрос о том делать ли автоматом мапп реста на крад и мне кажется контроллер на модель не натягивают (рест). И уж тем более не рашают какие действия у модели должны быть (крад) что на 2х уровнях я уж разбурусь что значит post /user/42 и с чем это кушать.
Последнее редактирование:
Блин, да слазьте вы в спецификацию, REST он вообще про другое, он про клиент-сервер, про отсутствие состояния, про кеширование и слои, причём на сетевом уровне. А интерфейс апи - это крохотная его часть, и VERB /resource/id/action - это одна из предложенных реализаций, которая вовсе не является единой и верной. Все эти VERB нужны даже не для самого серверного апи, а для сетевых слоёв, так как позволяют гибко маршрутизировать запросы, подчищать кеш, балансировать нагрузку и т.д.
REST он про работу по сети, а не название методов.
Видел проект, где GraphQL вкручивать начали, потому что постеснялись в апи параметр отвещающий за набор полей, мол это будет не по ресту.
REST он про работу по сети, а не название методов.
Видел проект, где GraphQL вкручивать начали, потому что постеснялись в апи параметр отвещающий за набор полей, мол это будет не по ресту.
я попробую последний раз, ну да в общем не стою.
нужен сервис который группирует несколько sql-запросов в один
удобно было бы чтоб сервер вместо этих 2х запросов исполнил 1
решение типа rest
выкидываем логику на клиента, собираем новый state на клиенте, и пулим его через update /user/42
rest не запрещает делить на отдельные запросы, также на каждый update мы можем по набору параметров разделить на сервисные процедуры,
мы в контроллере решаем по каким правилам, что и как и в какой последовательности должно происходить.
и мы легко исполним 2 вызова сервиса получив при этом 1 запрос
нужен сервис который группирует несколько sql-запросов в один
Код:
update users set firstname='вася' where id=42;
update users set lastname='пупкин' where id=42;
Код:
update users set firstname='вася', lastname='пупкин' where id=42;выкидываем логику на клиента, собираем новый state на клиенте, и пулим его через update /user/42
rest не запрещает делить на отдельные запросы, также на каждый update мы можем по набору параметров разделить на сервисные процедуры,
мы в контроллере решаем по каким правилам, что и как и в какой последовательности должно происходить.
и мы легко исполним 2 вызова сервиса получив при этом 1 запрос
угу.сложно понять на какой. Но тут мы говорили о группировке нескольких запросов.
Правда никому в голову не придет делать запросы
какими-то отдельными.
Обычно группируют запросы вида изменения некой entity и get ее измененную версию. Такие вот запросы удобно сделать за один раз. Но причем тут rest я понять не могу
Правда никому в голову не придет делать запросы
Код:
update users set firstname='вася' where id=42;
update users set lastname='пупкин' where id=42;Обычно группируют запросы вида изменения некой entity и get ее измененную версию. Такие вот запросы удобно сделать за один раз. Но причем тут rest я понять не могу
Это и произошло, только там, на клиенте
Иногда мне кажется(на самом деле я в этом уверен) что некоторые люди , когда создают веб-приложения, думают как лучше и проще всего организовать потоки данных между HTML(HTTP) и базой данных. По большому счету, веб-приложение этим и занимается. Но для сложных приложений такой подход вредит. Думать надо моделью. И лишь потом как организовать ее взаимодействие между базой, HTML(HTTP) и так далее.
И судя по некоторым фразам, товарищ @WMix из числа первых.
И судя по некоторым фразам, товарищ @WMix из числа первых.
Вурдалак
Продвинутый новичок
Что меня больше напрягает, так это то, что примеры сводятся к тому, как красиво, легко и просто можно сменить имя. Имя, Карл. Я такие свойства даже в domain model не размещаю, они обычно только в read model, которая получает изменения через события.
Я для истории ещё один пример приведу, с моей точки зрения очень показательный. Если кому-то доводилось реализовать на стороне сервера подписки AppStore, то они надолго запомнят этот ад с километровыми списками транзакций, тонной свойств и отсутствием каких-нибудь признаков действий: всё сводится к тому, что разработчики сами должны понимать, что же произошло. Клиент тут тоже никак не мог помочь, поскольку Apple приложениям тоже по сути ничего не сообщает, просто — вот тебе зашифрованный receipt, иди отправляй на сервер, они там как-нибудь разберутся. Вдобавок к этому, там прыгающие айдишники транзакций (справедливости ради, они вроде как незадокументированы, но зачем они вообще там присутствуют, если они могут меняться?) и отсутствие чёткого разделения разовых покупок и действий с подписками: по сути всё в одной большой куче. Нам пришлось потратить прилично времени, чтобы делать anti-corruption layer, который конвертировал этот abomination в чёткий список действий, который произошёл с подписками пользователя: старт новой подписки, продление, смена плана, продление периода отсрочки (когда подписка по факту закончилась, но Apple не оставляет надежд, что вот-вот пользователь пополнит свою карту и не закрывает подписку). Стало нереально проще понимать, что именно происходит, на полученный список событий мы навесили логгирование, оказание услуг, статистику и т.д.
И вот этим летом Apple всё-таки одумались и сделали серьёзный шаг вперед: server-to-server уведомления, которые содержат предельно чёткое название события, которое произошло с подписками: старт, отмена (этого вообще не было), автоматическое продление, «ручное» продление, ...:
INITIAL_BUY, CANCEL, RENEWAL, INTERACTIVE_RENEWAL, ... И подключение этого уже после проделанной работы оказалось по сути бесплатным, поскольку у нас были ровно такие же команды, оставалось только каждому notification_type сопоставить соответствующее действие нашей модели. И понимать такой API стало на порядке проще, потому что в случае с огромным receipt мы занимались реверс-инжинирингом, чтобы понять что в принципе может происходить.
Мораль такова, что если в проекте есть логика, то нужно искать глаголы, точно отражающие процессы в системе, это помогает всем вовлечённым в проект: и клиенту, и серверу и даже менеджерам. Становится просто легче держать в голове логику, понимать разницу между кажущимися одинаковыми (с точки зрения CRUD-одержимых) действиями. А если ваши проекты состоят из сплошных обновлений профиля пользователя, то установите клиенту Joomla и не трахайте никому мозги, вы просто занимаетесь интерфейсами к базам данных, а для этого уже давно придумали удобные инструменты.
Я для истории ещё один пример приведу, с моей точки зрения очень показательный. Если кому-то доводилось реализовать на стороне сервера подписки AppStore, то они надолго запомнят этот ад с километровыми списками транзакций, тонной свойств и отсутствием каких-нибудь признаков действий: всё сводится к тому, что разработчики сами должны понимать, что же произошло. Клиент тут тоже никак не мог помочь, поскольку Apple приложениям тоже по сути ничего не сообщает, просто — вот тебе зашифрованный receipt, иди отправляй на сервер, они там как-нибудь разберутся. Вдобавок к этому, там прыгающие айдишники транзакций (справедливости ради, они вроде как незадокументированы, но зачем они вообще там присутствуют, если они могут меняться?) и отсутствие чёткого разделения разовых покупок и действий с подписками: по сути всё в одной большой куче. Нам пришлось потратить прилично времени, чтобы делать anti-corruption layer, который конвертировал этот abomination в чёткий список действий, который произошёл с подписками пользователя: старт новой подписки, продление, смена плана, продление периода отсрочки (когда подписка по факту закончилась, но Apple не оставляет надежд, что вот-вот пользователь пополнит свою карту и не закрывает подписку). Стало нереально проще понимать, что именно происходит, на полученный список событий мы навесили логгирование, оказание услуг, статистику и т.д.
И вот этим летом Apple всё-таки одумались и сделали серьёзный шаг вперед: server-to-server уведомления, которые содержат предельно чёткое название события, которое произошло с подписками: старт, отмена (этого вообще не было), автоматическое продление, «ручное» продление, ...:
INITIAL_BUY, CANCEL, RENEWAL, INTERACTIVE_RENEWAL, ... И подключение этого уже после проделанной работы оказалось по сути бесплатным, поскольку у нас были ровно такие же команды, оставалось только каждому notification_type сопоставить соответствующее действие нашей модели. И понимать такой API стало на порядке проще, потому что в случае с огромным receipt мы занимались реверс-инжинирингом, чтобы понять что в принципе может происходить.
Мораль такова, что если в проекте есть логика, то нужно искать глаголы, точно отражающие процессы в системе, это помогает всем вовлечённым в проект: и клиенту, и серверу и даже менеджерам. Становится просто легче держать в голове логику, понимать разницу между кажущимися одинаковыми (с точки зрения CRUD-одержимых) действиями. А если ваши проекты состоят из сплошных обновлений профиля пользователя, то установите клиенту Joomla и не трахайте никому мозги, вы просто занимаетесь интерфейсами к базам данных, а для этого уже давно придумали удобные инструменты.
можно представить многопользовательскую игру у которой есть возможность работать offline. все что не связано с взаимодействием с другими пользователями можно использовать на клиенте без подключения. к примеру сим сити, строить можно офлайн, торговать только онлайн. при подключении игра синхронизирует состояние с сервером.
сел пользователь значит в самолет отключил связь и начал играть
построил дом (потерял бабло), передвинул дом, передвинул дом,.. этот список событий может быть огромный, при этом есть множество событий которые не изменили состояния кошелька, но состояние карты. другие события протекают на такт времени (собрали налог). сумма налога зависит от времени когда дом построен. ну в смысле события желательно запоминать как они были, иначе сложно проверить клиента.
вернемся к серверу. самолет приземлился, появилась связь, необходимо синхронизировать состояние. я надеюсь что на каждое событие ты не будешь делать запрос а отправишь массу событий на сервер за один раз. не нужна эта бизнес логика (построй, перенеси) в протоколе передачи данных. обычного rest "добавь историю игры" будет вполне достаточно. при этом в моделе у тебя список событий.
сел пользователь значит в самолет отключил связь и начал играть
построил дом (потерял бабло), передвинул дом, передвинул дом,.. этот список событий может быть огромный, при этом есть множество событий которые не изменили состояния кошелька, но состояние карты. другие события протекают на такт времени (собрали налог). сумма налога зависит от времени когда дом построен. ну в смысле события желательно запоминать как они были, иначе сложно проверить клиента.
вернемся к серверу. самолет приземлился, появилась связь, необходимо синхронизировать состояние. я надеюсь что на каждое событие ты не будешь делать запрос а отправишь массу событий на сервер за один раз. не нужна эта бизнес логика (построй, перенеси) в протоколе передачи данных. обычного rest "добавь историю игры" будет вполне достаточно. при этом в моделе у тебя список событий.