Здравствуйте, Mihas, Вы писали:
M>bnk У нас например все DELETE и PUT блокируются на роутерах, M>Поясни, плиз. M>Так работают роутеры, локализованные для вашей страны? Или я что-то не так понял?
Не, не для страны конечно
Внутри организации, где сейчас работаю (большая гос. контора), заблокировано все кроме POST и GET.
Т.е. у меня на работе 2 машины по сути — одна с подключением к "внутренней" сети организации с кучей странных блокировок, которая к тому же физически отключена ото всего остального —
даже файлы туда на флешках перетаскивают, и другая — "нормальная", подключенная к интернету, без проблем с PUT и DELETE.
Понимаю, что сценарий довольно экзотический, но возможный.
Здравствуйте, Sharov, Вы писали:
S>Но желательно пересмотреть архитектуру, например когда надо сделать запросы по ид от 1 до 10
Судя по всему речь идет об UUID и задача типовая — обновить на клиенте пакетно или даже транзакционно список объектов.
Здравствуйте, ·, Вы писали:
·>Т.е. появляется куча проблем. Мало того, это делает сервис stateful, т.е. лишняя головная боль для load balancer, вставляя палки в колёса scalability. Увеличивает latency — нужно два запроса вместо одного.
На уровне контракта API достаточно сказать, что некоторая часть результатов возвращается сразу плюс ссылка на следующие. Начальная реализация сервера возвращает сразу всё, клиент сразу умеет дочитывать, в дальнейшем можно реализовать более умный сервер. Именно такая операция (синхронизация объектов по UUID или ссылкам на self) является достаточно распространенной, поэтому легко выделяется в архитектурный шаблон в коде.
Технически можно передавать тело в GET-запросе. Хотя это немного нестандартный подход и он не рекомендуется, очень многие клиенты и серверы позволяют это делать.
