Я написал ровно то, что написал. Не ищите в этом больше. Отличить REST от простого HTTP запроса невозможно. Не зная, что это REST запрос. Это позволяет смотреть на REST проще, не загоняясь во все эти казуистические дебри — кто, что сказал в каком году про REST. А рассматривать мощь REST ввиду полного использования им «магии» HTTP.
Основное назначение UUID — это позволить распределённым системам уникально идентифицировать информацию без центра координации. Таким образом, любой может создать UUID и использовать его для идентификации чего-либо с приемлемым уровнем уверенности, что данный идентификатор непреднамеренно никогда не будет использован для чего-то ещё.
Остальное решается простым правилом — доверяй, но проверяй. Валидация на сервере решит эту проблему при синхронизации с клиентом.
Никто не мешает сделать два RPC запроса вместо одного.
Здравый смысл мешает. Это создание дополнительных требований к протоколу. И попытка получить от RPC несвойтсвенное ему поведение. Конечно, никто это запретить делать не может. Но для этого уже есть REST. Протокол JSON-RPC не ограничивает число запросов в batch. На том и стоим. Ручное ограничение это уже не JSON-RPC.
В этом суть. Создание роисходит с уже указанным UUID, который сгенерирован на стороне клиента. Т.е. он о нем уже знает. А не угадывает существующего пользователя.
Тем, что система доверяет, но проверяет. А не не доверяет и сама все делает.
В первом случае ты волен делать что угодно, но в конце результат будет проверен. Во втором случае, ты ничего не можешь делать пока тебе не дадут то, без чего ты не можешь начать.
Он, возможно, прочитает не то описание и увидит не ту цену. При стечении негативных обстоятельств. Но заплатить не ту сумму у него не выйдет. Т.к. транзакция оплаты будет валидироваться по актуальным данным. Тут-то все и встанет на места.
Ни один клиент при этом не пострадает ;)
А вот над оперативностью обновления можно думать, но не загоняться. Потому, что так можно предполажить, что клиент открыл страницу… смотрит на нее 2 часа и потом наживает кнопку купить. А за эти два часа товар поменял описание и цену. Результат тот же. Но кэш тут в общем-то не виноват. Точнее это уже кэш пользователя зафейлил информацию.
В целом да. Но атака UUID такая себе штука. Вся проблема заключается в том, что самое плохое, что может возникнуть — коллизия. А этот контроль, в любом случае, осуществляется на «принимающей стороне».
Придумать «плохой» UUID так же сложно как «хороший»;)
Не… GUID делался как раз для того, чтобы любой мог его генерировать и использовать без синхронизации с другим (не спрашивая). А UUID это конкретная реализация класса GUID.
Это крайне важная составляющая распределенных хранилищ.
Из комментом, я вынес для себя то, что есть еще одна интересная тема — управление распределенным хранилищем. Думаю, стоит ее затронуть. И клиент там будет очень важной и нагруженной частью. А uuid, ключевой штукой, которая позволит клиенту частично получать сервис даже в offline.
И да и нет. «Хитрые» роуты решают вопрос в случае, когда ты уверен, что не будет атаки на инфраструктуру с целью ее перегрузить.
Запросы за авторизацией, не часто нужно кэшировать. Просто потому, что действия пользователя чаще всего разнообразные, а возвращаемый контент уникальный. Т.е. кэш тут попросту ничего не дает. Но иногда и их нужно. Например, когда пользователь получает доступ к статическим файлам (скажем медиабиблиотеке) просто потому, что он залогинился.
Прекрасные новости! Нужные фичи!
И какой он? Первый. Напишите тут плз его uuid.
Спасибо. Теперь я знаю. Мой мир более не будет прежним.
А что нет?
Идентификатор пользователя в парадигме REST это URI на пользователя. По которому, затем выполняются методы обогащения.
Мне кажется, что вы все же не подумали перед ответом. Жаль.
Советую хорошо все перепроверить перед ответом.
Мне кажется конструктив закончился. Спасибо за комментарии!
Остальное решается простым правилом — доверяй, но проверяй. Валидация на сервере решит эту проблему при синхронизации с клиентом.
Здравый смысл мешает. Это создание дополнительных требований к протоколу. И попытка получить от RPC несвойтсвенное ему поведение. Конечно, никто это запретить делать не может. Но для этого уже есть REST. Протокол JSON-RPC не ограничивает число запросов в batch. На том и стоим. Ручное ограничение это уже не JSON-RPC.
В этом суть. Создание роисходит с уже указанным UUID, который сгенерирован на стороне клиента. Т.е. он о нем уже знает. А не угадывает существующего пользователя.
Yep.
В первом случае ты волен делать что угодно, но в конце результат будет проверен. Во втором случае, ты ничего не можешь делать пока тебе не дадут то, без чего ты не можешь начать.
Ни один клиент при этом не пострадает ;)
А вот над оперативностью обновления можно думать, но не загоняться. Потому, что так можно предполажить, что клиент открыл страницу… смотрит на нее 2 часа и потом наживает кнопку купить. А за эти два часа товар поменял описание и цену. Результат тот же. Но кэш тут в общем-то не виноват. Точнее это уже кэш пользователя зафейлил информацию.
Придумать «плохой» UUID так же сложно как «хороший»;)
Это крайне важная составляющая распределенных хранилищ.
Из комментом, я вынес для себя то, что есть еще одна интересная тема — управление распределенным хранилищем. Думаю, стоит ее затронуть. И клиент там будет очень важной и нагруженной частью. А uuid, ключевой штукой, которая позволит клиенту частично получать сервис даже в offline.
Запросы за авторизацией, не часто нужно кэшировать. Просто потому, что действия пользователя чаще всего разнообразные, а возвращаемый контент уникальный. Т.е. кэш тут попросту ничего не дает. Но иногда и их нужно. Например, когда пользователь получает доступ к статическим файлам (скажем медиабиблиотеке) просто потому, что он залогинился.