#http #rest
#http #rest
Вопрос:
Вот вопрос для вас, фанатов RESTful. Позвольте мне подготовить почву.
Допустим, у меня есть удаленная система под названием ChickenShack и локальная система под названием BurgerShack, обе из которых интегрированы таким образом, что каждая система поддерживает «синхронизированную» копию данных объекта. Когда происходит изменение объектов в ChickenShack, он отправляет коллекцию идентификаторов этих объектов в виде запроса RESTful в BurgerShack. Затем BurgerShack отправляет запрос GET в ChickenShack, запрашивая все атрибуты измененной сущности и обновляя локальную копию сущности.
Все это асинхронно и разработано с учетом определенных ограничений (так что, если вам это кажется невкусным, поймите, что в жизни иногда нам приходится есть дерьмо и улыбаться).
Мой вопрос: должен ли первоначальный запрос, отправленный из ChickenShack в BurgerShack, быть запросом GET или PUT? Поскольку первоначальный запрос является идемпотентным, часть меня говорит «GET». Тем не менее, это в конечном итоге приводит к изменению данных в Burger, поэтому другая часть меня говорит «ПОМЕСТИТЬ» или «ОПУБЛИКОВАТЬ».
Что вы думаете?
Комментарии:
1. Касательная точка, но обратите внимание, что PUT также является идемпотентным.
2. 1 за то, что вы поставили меня в известность о том, что websequencediagrams.com существует, если нет другой причины. Вау.
Ответ №1:
Я бы выбрал POST , потому что:
- он изменяет состояние в BurgerShack (я не думаю, что это идемпотентно, потому что он запускает GETs из BurgerShack в ChickenShack)
- он не создает новый ресурс по этому конкретному URL (что исключает
PUT)
Комментарии:
1. 1, также: GET было бы неуместно (вы не получаете доступ к ресурсу burger). И, как указано @Waldheinz, PUT не подходит (вы не создаете ресурс burger)
2. Он идемпотентен. Вы можете повторить POST и в конечном итоге получить то же состояние в BurgerShack.
3. @Paul Есть разница между can и have to , чтобы запрос был идемпотентным, должно быть гарантировано, что вы можете повторить его без изменения состояния.