Re[11]: REST: прохой\хороший интерфейс
От: Cyberax Марс  
Дата: 04.02.20 18:59
Оценка: +2
Здравствуйте, Sinclair, Вы писали:

S>Понятно, что в общем случае "просто выбрать PUT" недостаточно; я вот прямо сейчас наблюдаю чудеса во вполне РЕСТ-овом API от Microsoft (https://docs.microsoft.com/en-us/partner-center/develop/partner-center-rest-api-reference), где парни ухитрились на ровном месте сделать невозможным предотвращение двоящихся или потерянных заказов.

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

S>Я так понимаю — как раз потому, что они не очень хорошо понимали, что такое REST, и задумывались о "стратегиях, которые гораздо важнее". Идемпотентность в старом order api они обеспечивали через custom header "Request-ID", а в новом shopping cart команде просто об этом хидере не рассказали.

Это одна из причин, по которой я не люблю REST. Информация слишком сильно размазана — по заголовкам, глаголу и телу запроса. Точно так же с ошибками — нет одного явного способа сообщать их.
Sapienti sat!
Re[8]: REST: прохой\хороший интерфейс
От: Doc Россия http://andrey.moveax.ru
Дата: 05.02.20 02:59
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Если сам по себе — то ничего страшного, у нас получилось 2 (3, и т.д.) "копии" объекта. Т.е. имеем что-то типа набора версий, которые существуют более-менее независимо. "Сломать" объект нельзя, всегда можно вернуться к "старому" id и применить к нему другую трансформацию.


Но ведь по определению PUT при существующем ID объекта, он должен модифицировать объект. Поэтому такой подход для меня выглядит странно.
Я понимаю, что тут реально можно натянуть сову на глобус, оперируя поведением BL, но это уже рассуждение об абстрактной BL. Тут можно что угодно нафантазировать (нам же ее не имплементировать и не поддерживать )
Re[12]: REST: прохой\хороший интерфейс
От: Sinclair Россия https://github.com/evilguest/
Дата: 05.02.20 06:26
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Ну вот им как раз нужно было думать не о глаголах, а об API. Если есть ключ идемпотентности — надо явно вносить его в тело запроса, а не играться с заголовками.

Если бы они думали о глаголах, то Create an Order выполнялось бы через PUT.
И никакого "ключа идемпотентности" бы не потребовалось. Но там работают ваши единомышленники, и они решили, что "а захреначу как я всё через POST".

Потом пришло второе поколение, которое про REST знало ещё меньше. Поэтому новый API, построенный на Create Cart / Checkout Cart, в принципе не позволяет добиться идемпотентности. При определённом стечении событий, можно ухитриться купить товар, и потерять об этом информацию.

C>Это одна из причин, по которой я не люблю REST. Информация слишком сильно размазана — по заголовкам, глаголу и телу запроса. Точно так же с ошибками — нет одного явного способа сообщать их.

Мне кажется, что вы просто не разобрались с REST. Самовыдуманные хидеры в нём не нужны.
С ошибками — да, одного способа нет.
Тем не менее, есть вполне нормальные решения на уровне договорённостей конкретного API: возвращаем структурированный JSON, в котором есть как код ошибки, так и сообщение, локализованное с учётом предпочтений клиента.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[9]: REST: прохой\хороший интерфейс
От: Sinclair Россия https://github.com/evilguest/
Дата: 05.02.20 06:39
Оценка:
Здравствуйте, Doc, Вы писали:

Doc>Но ведь по определению PUT при существующем ID объекта, он должен модифицировать объект. Поэтому такой подход для меня выглядит странно.

Ок, тут я несколько скомкал изложение. Вы правы — делать PUT, который самопроизвольно порождает новые объекты — плохо.
Делаем примерно так:
1. Внутрь объекта спрятана его версия. Когда мы делаем PUT, мы делаем инкремент известной нам версии на единичку. На сервере мы проверяем — выделяется три случая:
— версия на сервере N, пришла версия N+1 — сохраняем, 200 OK
— версия на сервере N, пришла версия N, контент совпадает — отдаём 200 Ok (idempotence)
— версия на сервере N, пришла версия N, контент не совпадает, либо пришла любая другая версия — отдаём 409 Conflict.
При этом старые версии объекта могут быть независимо доступны для чтения через отдельные адреса.
2. Версия объекта является частью его URL. Тогда редактирование делается при помощи POST, и каждый POST порождает новую версию где-то "рядом" с оригиналом.
Мы имеем право возвращать не новый URL каждый раз, а в случае совпадения с какой-либо из существующих версий возвращать её URL. Тогда мы заодно получаем идемпотентность — многократный POST с одним и тем же body будет возвращать один и тот же URL
Doc>Я понимаю, что тут реально можно натянуть сову на глобус, оперируя поведением BL, но это уже рассуждение об абстрактной BL. Тут можно что угодно нафантазировать (нам же ее не имплементировать и не поддерживать )
Снова возвращаемся к вопросу о требованиях. Без них решительно невозможно сравнивать характеристики разных решений, и всё упирается в "я не люблю глаголы за пределами GET и POST" или "я не люблю искусственные ключи идемпотентности".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[13]: REST: прохой\хороший интерфейс
От: Cyberax Марс  
Дата: 05.02.20 07:47
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Если бы они думали о глаголах, то Create an Order выполнялось бы через PUT.

S>И никакого "ключа идемпотентности" бы не потребовалось. Но там работают ваши единомышленники, и они решили, что "а захреначу как я всё через POST".
АБСОЛЮТНО И В КОРНЕ <b>НЕВЕРНО</b>!

Сам по себе PUT никоим образом не спасёт от двойного создания объекта. Просто теряем сетевое соединение при ответе и клиент получает что-нибудь типа 509 Gateway Error и упс. Всё что он может — повторить запрос, который может создать объект заново.

В REST конкретно все PUT/POST/GET/whatever — это чисто декорация, простейший вариант документации.

C>>Это одна из причин, по которой я не люблю REST. Информация слишком сильно размазана — по заголовкам, глаголу и телу запроса. Точно так же с ошибками — нет одного явного способа сообщать их.

S>Мне кажется, что вы просто не разобрались с REST.
LOL.

S>Самовыдуманные хидеры в нём не нужны.

Ну вот тут же уже примеры с Request Id были.

S>С ошибками — да, одного способа нет.

S>Тем не менее, есть вполне нормальные решения на уровне договорённостей конкретного API: возвращаем структурированный JSON, в котором есть как код ошибки, так и сообщение, локализованное с учётом предпочтений клиента.
А ещё есть ответы с ошибками от load balancer'а в теле вместо ошибки. Или некоторые API, которые используют строку ответа HTTP.

Так же добавляются кривые стандарты (Swagger/OpenAPI) и получаем полное бинго.
Sapienti sat!
Re[14]: REST: прохой\хороший интерфейс
От: Sinclair Россия https://github.com/evilguest/
Дата: 05.02.20 11:58
Оценка:
Здравствуйте, Cyberax, Вы писали:
C>Сам по себе PUT никоим образом не спасёт от двойного создания объекта.
C>Просто теряем сетевое соединение при ответе и клиент получает что-нибудь типа 509 Gateway Error и упс. Всё что он может — повторить запрос, который может создать объект заново.
Совершенно верно. Вот тут-то и спасает идемпотентность PUT. Что именно вам непонятно?
Если мы получили 5xx, то у нас есть два варианта вернуться к синхронности:
1. Продолжать долбить тот же PUT, до получения однозначности: либо 4xx, который означает что создание точно сфейлилось, либо 2хх, который означает, что создание точно удалось.
2. Попробовать выполнять GET на тот же адрес, до получения однозначности: либо 200 Ok (возможно, с последующей проверкой, что контент — тот, что мы ожидаем), либо 404.

Заметьте, всё ещё никаких кастомных хидеров или искусственных ключей идемпотентности.

C>В REST конкретно все PUT/POST/GET/whatever — это чисто декорация, простейший вариант документации.

В REST просто вопросы восстановления после сбоев прошиты в этой самой "декорации". Банальное следование дисциплине приводит к надёжным реализациям.
Использование POST не накладывает никаких обязанностей, и провоцирует разработчиков косячить. Пример тому мы наблюдаем по той ссылке, которую я привёл.

S>>Мне кажется, что вы просто не разобрались с REST.

C>LOL.
Пока что впечатление сохраняется — судя по вашим комментариям про PUT и 509 Gateway Error.

C>Ну вот тут же уже примеры с Request Id были.

Где? В примере про злоупотребление POST там, где нужно PUT?

C>А ещё есть ответы с ошибками от load balancer'а в теле вместо ошибки. Или некоторые API, которые используют строку ответа HTTP.

C>Так же добавляются кривые стандарты (Swagger/OpenAPI) и получаем полное бинго.
Это не вина REST как такового. REST закладывает достаточно основ для того, чтобы можно было отличить сбой от успеха, и retyable error от fatal error.
Как минимальная база — ок. Дальнейшие улучшения, как и все остальные улучшения, требуют дизайна. Строка ответа HTTP — это, скорее всего, плохой дизайн. Если он действительно плохой (а я вполне могу себе представить задачу, где он вполне Ок), то его авторы бы навелосипедили плохой дизайн и в любом другом подходе к проектированию API.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[15]: REST: прохой\хороший интерфейс
От: AndrewJD США  
Дата: 05.02.20 17:18
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>1. Продолжать долбить тот же PUT, до получения однозначности: либо 4xx, который означает что создание точно сфейлилось, либо 2хх, который означает, что создание точно удалось.

Так сервер уже вернул 2хх, а клиент получил 5хх. Как это разрулить без ключа?
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Re[16]: REST: прохой\хороший интерфейс
От: Sinclair Россия https://github.com/evilguest/
Дата: 06.02.20 02:51
Оценка:
Здравствуйте, AndrewJD, Вы писали:

AJD>Здравствуйте, Sinclair, Вы писали:


S>>1. Продолжать долбить тот же PUT, до получения однозначности: либо 4xx, который означает что создание точно сфейлилось, либо 2хх, который означает, что создание точно удалось.

AJD>Так сервер уже вернул 2хх, а клиент получил 5хх. Как это разрулить без ключа?
Продолжать долбить тот же PUT, до получения однозначности: либо 4xx, который означает что создание точно сфейлилось, либо 2хх, который означает, что создание точно удалось.
Ключом в данном случае выступает адрес объекта. Главное слово: идемпотентность. Какой именно сценарий вам непонятен?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re: REST: прохой\хороший интерфейс
От: · Великобритания  
Дата: 06.02.20 12:38
Оценка:
Здравствуйте, a.v.v, Вы писали:

AVV>Во многих вакансиях появилось требование звучащее как — уметь проектировать хороший rest интерфейс

AVV>вот и задумался а что такое этот хороший интерфейс, у самого есть конечно мысли но какие то они не очень убедительные
Некоторые детали уже рассказали, попробую сформулировать общую философию.
Надо осознать, что REST это не простой RPC между клиентом и сервером в локалке, а протокол взаимодействия распределённых гетерогенных систем в условиях дикого интернета.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[2]: REST: прохой\хороший интерфейс
От: Буравчик Россия  
Дата: 06.02.20 14:36
Оценка:
Здравствуйте, ·, Вы писали:

·>Здравствуйте, a.v.v, Вы писали:


AVV>>Во многих вакансиях появилось требование звучащее как — уметь проектировать хороший rest интерфейс

AVV>>вот и задумался а что такое этот хороший интерфейс, у самого есть конечно мысли но какие то они не очень убедительные
·>Некоторые детали уже рассказали, попробую сформулировать общую философию.
·>Надо осознать, что REST это не простой RPC между клиентом и сервером в локалке, а протокол взаимодействия распределённых гетерогенных систем в условиях дикого интернета.

Все, что можно сделать в REST, можно и в RPC.
Хотелось бы услышать список преимуществ REST перед RPC.

Основное различие — REST оперирует ресурсами, а RPC — операциями. Но при проектировании обычно так: У нас есть 10 операций, давайте натянем их на REST (спроектируем ресурсы, применим к ним глаголы). Потом в документации напишем, чтобы выполнить операцию 1 — работаем с такими-то ресурсами, операцию 2 — с такими-то.

В RCP ничего этого не надо — есть операция, есть вход, есть выход.
Best regards, Буравчик
Re[3]: REST: прохой\хороший интерфейс
От: · Великобритания  
Дата: 06.02.20 15:04
Оценка:
Здравствуйте, Буравчик, Вы писали:

Б>Все, что можно сделать в REST, можно и в RPC.

Тут дело не в том, что можно сделать, а что нельзя. Это примерно то же отличие, как в стилях программирования. Скажем, всё что умеет функциональное программирование можно сделать процедурно. Но отличие-то есть!

Б>Хотелось бы услышать список преимуществ REST перед RPC.

Суть в том, что REST акцентирует внимание на такие делали, которые RPC просто игнорирует и которые больно кусают, но потом, и только если что-то пошло немного не так.

Б>Основное различие — REST оперирует ресурсами, а RPC — операциями. Но при проектировании обычно так: У нас есть 10 операций, давайте натянем их на REST (спроектируем ресурсы, применим к ним глаголы). Потом в документации напишем, чтобы выполнить операцию 1 — работаем с такими-то ресурсами, операцию 2 — с такими-то.

Терминология позволяет обращать внимание на важные аспекты взаимодействия распределённых систем. Но, естественно, можно проектировать и RPC правильно, используя те же идеи, типа идемпотентности. А REST уже есть сформированный понятийный словарь, который понятен другим и переизобретать ничего не надо.

Б>В RCP ничего этого не надо — есть операция, есть вход, есть выход.

Угу. А если связь оборвалась — что выход? И что результат? И как об этом узнать?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[3]: REST: прохой\хороший интерфейс
От: scf  
Дата: 06.02.20 15:15
Оценка: 2 (1)
Здравствуйте, Буравчик, Вы писали:

Б>Все, что можно сделать в REST, можно и в RPC.

Б>Хотелось бы услышать список преимуществ REST перед RPC.

Для начала, что такое REST, без фанатизма и упоротости.
REST — это способ реализации RPC, опирающийся на стандарты и best practices для HTTP и связанных rfc, и способ формирования ендпоинтов RPC на основе концепции ресурсов.

Первое и главное, REST сделан для людей, не для машин. Все знают REST, т.е. заранее известно:
— как передавать обязательные и необязательные параметры, как получить и распарсить результат
— какие вызовы меняют состояние, а какие просто возвращают данные
— какие вызовы идемпотентны, а какие создают новые сущности
— как возвращаются ошибки, какие ошибки retryable, какие non-retryable
— как делается аутентификация и авторизация
— как ориентироваться в API

Второе, иерархичность. Понятия "ресурс", CRUD над ресурсом и вложенные ресурсы в урле оказались Хорошей Идеей. Удобной для человека, удобной для развития апи, когда разные версии можно держать на одном днс с разными префиксами. Иерархичные ресурсы также очень удобно обмазывать авторизацией, разрешая или запрещая доступ по префиксам урлов.

Третье, популярность и доступнсть. Есть огромное количество тулов для отправки REST запросов, от браузера и curl до специализированных приложений.

Четвертое, стандартность и расширяемость. Если вдруг захочется странного, часто можно раскопать RFC с нужным функционалом и не изобретать своё решение.
Re[3]: REST: прохой\хороший интерфейс
От: Sinclair Россия https://github.com/evilguest/
Дата: 07.02.20 07:10
Оценка: 52 (7)
Здравствуте, Буравчик, Вы писали:

Б>Все, что можно сделать в REST, можно и в RPC.

Б>Хотелось бы услышать список преимуществ REST перед RPC.
Основное преимущество REST — более "естественная" поддержка неидеальности мира.
Основная модель RPC — это "black box", инкапсуляция поведения и состояния. Когда его проектировали, казалось, что это — хорошая идея; потому что она привычна императивным разработчикам, и позволяет изолировать подсистемы.
Б>Основное различие — REST оперирует ресурсами, а RPC — операциями.
REST оперирует состоянием. Самый простой пример: RPC говорит "включить свет", а REST говорит "свет должен стать включенным".
Семантической разницы, вроде бы, нет. Но есть разница в том, как обрабатывать сбои.
Б>Но при проектировании обычно так: У нас есть 10 операций, давайте натянем их на REST (спроектируем ресурсы, применим к ним глаголы).
Это с непривычки. Ну, как начинающий студент сначала строит фразу на родном языке, а потом переводит её на иностранный. А опытный — сразу думает готовыми конструкциями целевого языка.
Так и тут — опытный архитектор сходу видит в системе то состояние, которое он будет реплицировать.

Потом в документации напишем, чтобы выполнить операцию 1 — работаем с такими-то ресурсами, операцию 2 — с такими-то.

Б>В RCP ничего этого не надо — есть операция, есть вход, есть выход.

Вот именно это и плохо. RPC провоцирует людей думать о happy path, и вообще не задумываться о плохом — типа: а что делать, если "выход" потерялся.
REST, при последовательном следовании ему, заставляет проектировать систему надёжным образом.
К сожалению, вот именно это последовательное следование — большая редкость. Очень часто люди проектирут именно так, как вы сказали — вот 10 операций, давайте сделаем их POST-ом. Ну, то есть в RPC у нас было что-то типа
POST /lightOperations

{
   "operation":"switch",
   "targetLamp": 2144,
   "targetState": "on"
}


Вообще, из практики, бывает даже так, что из требований програм менеджера "должно поддерживаться включение/выключение света" ничего, кроме ровно этого метода, не происходит. Я не шучу — именно так был устроен MOSI API, созданный Microsoft примерно в 2011 году. Он был write only. Но если програм менеджер был более внимателен, или архитектор чуть менее идиот, то у нас будет работать и примерно вот такое:
POST /lightOperations

{
   "operation":"get",
   "targetLamp": 2144,
}

Когда разработчику, искалеченному RPC, ставят задачу "перевести всё на REST", он зачастую делает вот так:
GET /lamps/2144

Это аналог нашего "operation":"get" из предыдущего примера. Сразу получаем два преимущества перед RPC:
1. На этот раз архитектор не смог забыть про возврат состояния.
2. Запрос состояния сделан глаголом GET, и вся инфраструктура сразу же понимает последствия: результат запроса можно кэшировать; его можно смело повторять при сбое коммуникации, не боясь ничего сломать; получив 302 или 301 мы точно знаем, что можно безопасно следовать по указанному URL.

"Плохой" рест-архитектор затем делает вот так:
POST /lamps/2144/switch?state=on

Почему так делать плохо? Есть ряд причин:
1. Как обрабатывать двойное включение? Допустим, лампа уже on. Хочется вернуть 409 Conflict, но нельзя — возможно, клиент сделал POST, получил 502, и пытается снова. Увидев 409, он решит "я не смог включить" и запишет это как сбой.
Считать это успехом?
2. Что возвращать при успехе? 200 Ok? А в body что? Если состояние лампы, то это плохо — мы вынуждены протаскивать весь документ. Наверное, надо делать redirect-on-post и перекидывать на lamps/2144, и уже оттуда клиент получит состояние. Это даёт ему шанс, к примеру, получить delta-encoding, и при наличии в кэше предыдущего образца хорошо сэкономить на трафике.
3. В любом из вариантов нет связи между состоянием лампы и этим запросом. То есть, скажем, прокси, который хранит у себя /lamps/2144, должен каждый раз бегать на origin сервер с conditional get, чтобы держать кэш когерентным.

Если у нас чуть более сложная операция, вроде "увеличить яркость на 10%", то всё становится ещё хуже — в рамках RPC мы вообще не можем отличить потерянный POST от последовательного увеличения яркости. Если для switch?state=on у нас есть очевидная стратегия обработки повторных запросов (хотя бы на сервере), то для вот таких вот операций ничего хорошего нету.

Очень, очень велики шансы на то, что архитектор просто забудет об этом подумать. Потому что очень редкий програм или продакт менеджер расписывает все вот эти вот сценарии вроде "что делать, если запрос клиента не доехал до сервера", "что делать, если ответ сервера не доехал до клиента", "что делать, если между повторными запросами вклинился другой клиент с конфликтующим запросом" и прочие детали.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[4]: REST: прохой\хороший интерфейс
От: samius Япония http://sams-tricks.blogspot.com
Дата: 07.02.20 07:42
Оценка: 5 (1) +1
Здравствуйте, Sinclair, Вы писали:

S>Здравствуте, Буравчик, Вы писали:


Б>>Все, что можно сделать в REST, можно и в RPC.

Б>>Хотелось бы услышать список преимуществ REST перед RPC.
S>Основное преимущество REST — более "естественная" поддержка неидеальности мира.
S>Основная модель RPC — это "black box", инкапсуляция поведения и состояния. Когда его проектировали, казалось, что это — хорошая идея; потому что она привычна императивным разработчикам, и позволяет изолировать подсистемы.

Поставил "супер", но вот тут я принципиально не согласен. Не нужно противопоставлять RPC и REST вовсе. RPC — технология, позволяющая выполнить удаленный вызов и точка. REST — это архитектурный стиль организации работы распределенных приложений и сервисов. Это как сравнивать преимущества правил дорожного движения над автомобилем.
Re[17]: REST: прохой\хороший интерфейс
От: Ватакуси Россия  
Дата: 07.02.20 09:08
Оценка:
S>>>1. Продолжать долбить тот же PUT, до получения однозначности: либо 4xx, который означает что создание точно сфейлилось, либо 2хх, который означает, что создание точно удалось.
AJD>>Так сервер уже вернул 2хх, а клиент получил 5хх. Как это разрулить без ключа?
S>Продолжать долбить тот же PUT, до получения однозначности: либо 4xx, который означает что создание точно сфейлилось, либо 2хх, который означает, что создание точно удалось.
S>Ключом в данном случае выступает адрес объекта. Главное слово: идемпотентность. Какой именно сценарий вам непонятен?

И если одназночность так и не пришла, валить сервер DDOS-ом?
Все будет Украина!
Re[18]: REST: прохой\хороший интерфейс
От: Sharov Россия  
Дата: 07.02.20 11:00
Оценка:
Здравствуйте, Ватакуси, Вы писали:


В>И если одназночность так и не пришла, валить сервер DDOS-ом?


exponential back-off какой-нибудь...
Кодом людям нужно помогать!
Re[4]: интересное наблюдение
От: Sharov Россия  
Дата: 07.02.20 11:18
Оценка:
Здравствуйте, Sinclair, Вы писали:

Б>>Основное различие — REST оперирует ресурсами, а RPC — операциями.

S>REST оперирует состоянием. Самый простой пример: RPC говорит "включить свет", а REST говорит "свет должен стать включенным".

А вот это интересно -- у нас тут по образу и подобию происходит противопоставление двух подходов -- классического императивного и еще чего-то.
Обычно этим "чего-то" является ФП в мире языков, где почти полностью отсутсвует состоянии. А в мире сетевого взаимодействия ровно наоборот -- этот "чего-то"
как раз и является состоянием. Две крайности, а по середине императивщина.
Кодом людям нужно помогать!
Re[19]: REST: прохой\хороший интерфейс
От: Ватакуси Россия  
Дата: 07.02.20 11:19
Оценка:
В>>И если одназночность так и не пришла, валить сервер DDOS-ом?

S>exponential back-off какой-нибудь...

А смысл? 5xx почти всегда означает, что сервер не справился.
Все будет Украина!
Re[4]: REST: прохой\хороший интерфейс
От: Sharov Россия  
Дата: 07.02.20 11:35
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Так и тут — опытный архитектор сходу видит в системе то состояние, которое он будет реплицировать.


А причем тут опыт, если понятно, что реплицировать надо всю бд, ибо это и есть состояние?

S>3. В любом из вариантов нет связи между состоянием лампы и этим запросом. То есть, скажем, прокси, который хранит у себя /lamps/2144, должен каждый раз бегать на origin сервер с conditional get, чтобы держать кэш когерентным.


А можно подробнее зачем в этой цепочке client ->http post -->server еще и прокси? Или он тут нужен для инвалидации кэша, тогда какая ему разница какой запрос (форма запроса), главное что post/resourceid?

S>Если у нас чуть более сложная операция, вроде "увеличить яркость на 10%", то всё становится ещё хуже — в рамках RPC мы вообще не можем отличить потерянный POST от последовательного увеличения яркости. Если для switch?state=on у нас есть очевидная стратегия обработки повторных запросов (хотя бы на сервере), то для вот таких вот операций ничего хорошего нету.


А request id тут не поможет?
Кодом людям нужно помогать!
Re[15]: REST: прохой\хороший интерфейс
От: Cyberax Марс  
Дата: 09.02.20 06:18
Оценка:
Здравствуйте, Sinclair, Вы писали:

C>>Сам по себе PUT никоим образом не спасёт от двойного создания объекта.

C>>Просто теряем сетевое соединение при ответе и клиент получает что-нибудь типа 509 Gateway Error и упс. Всё что он может — повторить запрос, который может создать объект заново.
S>Совершенно верно. Вот тут-то и спасает идемпотентность PUT. Что именно вам непонятно?
Станьте ёжиками! Что тут непонятного?

Вот пример: "PUT /user\r\n\r\n{name: "Vasiliy", last_name: "Pupkin"}". Что тут происходит при двойном запуске? Будут созданы два пользователя или один пользователь?

Если два пользователя (ID=1,2), то в списке пользователей будем видеть лишний объект. Если же один пользователь, то тогда будет проблема, если нужно таки создать ДВУХ пользователей (Vasiliy Ivanovich Pupkin и Vasility Petrovich Pupkin).

И никакие мантры вида "PUT же идемпотентен" это не решают. Нужно сразу и заранее проектировать это, и там уже будет без разницы через какой глагол посылать запросы. Хоть через GET.
Sapienti sat!
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.