PUT или POST HTTP-команда при вызове конечной точки API, которая выполняет как UPDATE, так и INSERT?

У меня есть RESTful Web API (написанный на ASP .Net Core 2.1), который получает «журнал изменений» от клиентского приложения-потребителя. Это класс JSON, содержащий все изменения в базе данных, которые были выполнены в клиентском приложении, когда оно работало в автономном режиме. После того, как клиентское приложение переходит в онлайн, оно синхронизирует свою базу данных с онлайн-базой данных, отправляя API все изменения, произошедшие с момента последней синхронизации. Таким образом, он отправляет API набор изменений / журнал изменений с кучей списков UPDATE, INSERT и DELETE для различных таблиц / объектов.

Что касается API, я фактически ничего не удаляю из действующей базы данных - я просто помечаю вещи как удаленные (поэтому я устанавливаю логическое поле в значение true, т.е. deleted = true). Таким образом, технически API выполняет только ВСТАВКИ и ОБНОВЛЕНИЯ в базе данных.

Теперь я не согласен с тем, как клиент-потребитель должен называть эту конечную точку «синхронизации» API. Должен ли он называться POST или PUT-запросом? Поскольку API фактически выполняет как ОБНОВЛЕНИЯ, так и ВСТАВКИ ... Какой HTTP-глагол более уместен? Это вообще имеет значение?


api rest asp.net-core-webapi httpverbs
person Fabricio Rodriguez    schedule 12.09.2018    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Это скорее конвекция, и согласно соглашению у вас есть случай для POST, когда вы выполняете согласование. Рекомендуется использовать PUT для создания ресурсов или использовать POST для обновления ресурсов.

Также следует учитывать, что и PUT, и POST - небезопасные методы. Однако PUT идемпотентен, а POST - нет.

Почему бы не использовать PATCH

Из моих закладок - PUT vs. POST в REST и REST API - PUT vs PATCH с примерами из реальной жизни

person Sheetal Mohan Sharma    schedule 12.09.2018
comment
POST обычно создает ресурсы и обновления PUT, хотя оба могут выполнять и другое. POST - это универсальная операция, которую следует использовать, если ни один из других методов не является достаточно выразительным. PUT, т. Е. Также может иметь побочные эффекты. Хотя безопасность является важным обещанием для клиентов, которые не хотят изменять данные (например, веб-сканеры), если вам нужно сохранить данные, это скорее неважная функция. Чтобы оставаться в семантике PATCH, клиенту необходимо заранее рассчитать необходимые изменения и отправить их как атомарную инструкцию на сервер - либо все успешно, либо вообще ничего - person Roman Vottner; 12.09.2018
comment
Рекомендуемое чтение - person Roman Vottner; 12.09.2018

arrow_upward
1
arrow_downward

Могу рассказать о своем опыте. Глагол в остальных значениях ясен и не может быть неправильно понят. Но это не касается всех случаев.

Обычно я использую PUT только для обновления сущности, как определено. Чтобы охватить все остальные гибридные операции, я использую POST.

Итак, PUT api честный и чистый, и когда вы сталкиваетесь с POST, лучше копать еще немного!

person Lorenzo Isidori    schedule 12.09.2018
comment
Пожалуйста, прекратите использовать в качестве ссылки старый и давно устаревший RFC 2616. Он был заменен новым набором RFC: 7230-35. - person cassiomolin; 12.09.2018
comment
Хорошо, может быть, ты сможешь предложить нам новую ссылку. В любом случае, ответ не заслуживает голосования против. - person Lorenzo Isidori; 12.09.2018
comment
Спасибо за ссылку, Кассио. Интересно, что в нем говорится, что POST выполняет обработку данных запроса, зависящую от ресурса. В нем конкретно не упоминается ВСТАВКА. Так что, возможно, с этой точки зрения в этом случае будет уместным POST, поскольку я прошу API обработать предоставленную полезную нагрузку. - person Fabricio Rodriguez; 12.09.2018