Какой код состояния HTTP должен возвращать веб-API после успешного завершения, если он выполнял как ОБНОВЛЕНИЯ, так и ВСТАВКИ?

Question

Это дополнительный вопрос к моему предыдущему сообщению в HTTP-глаголе PUT или POST при вызове конечной точки API, которая выполняет UPDATE и INSERT?

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

Что касается API, я на самом деле ничего не удаляю из действующей базы данных - я просто помечаю вещи как удаленные (поэтому я установил для логического поля значение true, то есть delete = true). Технически, API выполняет только INSERTS и UPDATES для базы данных.

Какой код состояния должен возвращать метод действия API после успешного завершения? Так как он выполняет комбинацию как INSERTS, так и UPDATES, должен ли он вернуть 201 Created? Или просто 200 ОК? Или 200 OK, если были выполнены только обновления, или 201, если были выполнены какие-либо вставки? Кроме того, в теле ответа, поскольку я на самом деле не планирую возвращать какие-либо идентификаторы или объекты в теле (так как несколько объектов были бы обновлены и вставлены), я хотел бы вернуть просто обычный текст, сообщающий, сколько объектов было обновлено, как многие были вставлены, и сколько было помечено как удаленное. Это возможно, или даже хорошая идея?

Спасибо

Answer 1

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

Учитывая, что это больше RPC-подобный вызов, я бы вернулся 200 OK просто указывает на то, что операция прошла успешно.

Тем не менее, есть способ превратить это в нечто более похожее на REST.

Если у вас есть несколько ресурсов, базовые данные в этих ресурсах могут быть объединены и представлены в одном ресурсе, своего рода ресурс "коллекции".

Допустим, этот ресурс размещен на /clientstate/<client-id>, Делать GET возвращает весь ресурс clienttate.

Затем, чтобы обновить этот ресурс, вы должны использовать PUT заменить все состояние клиента. Для клиента совершенно неважно, что к одному ресурсу привязано несколько записей базы данных.

Если вы используете PUT чтобы заменить все это состояние клиента, тогда соответствующий код ответа должен быть 200 OK, Или возможно 204 No Content если ты не вернешь ничего интересного потом.

Я бы посоветовал не пересматривать 207 Multi-Status,

Answer 2

Кажется, это хорошая ситуация для 207, определенный в RFC 4918, расширение протокола HTTP:

11.1. 207 мульти-статус

207 Код состояния (Multi-Status) предоставляет статус для нескольких независимых операций.

Такой документ также гласит следующее:

13. Ответ нескольких статусов

Ответ о нескольких состояниях передает информацию о нескольких ресурсах в ситуациях, когда может потребоваться несколько кодов состояния. [...]

Хотя 207 используется в качестве общего кода состояния ответа, получатель должен просмотреть содержимое тела ответа о множественном статусе для получения дополнительной информации об успехе или неудаче выполнения метода. Ответ МОЖЕТ быть использован в случае успеха, частичного успеха, а также в ситуациях неудачи.

multistatus Корневой элемент содержит ноль или более response элементы в любом порядке, каждый с информацией об отдельном ресурсе. Каждый элемент "ответа" ДОЛЖЕН иметь href элемент для идентификации ресурса.

[...]