Какой код состояния HTTP должен возвращать веб-API после успешного завершения, если он выполнял операции UPDATES и INSERTS?

Question

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

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

На стороне API я фактически ничего не удаляю из действующей базы данных - я просто помечаю вещи как удаленные (поэтому я установил для логического поля значение true, т.е. удалено = 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 Multi-Status

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

В этом документе также говорится следующее:

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

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

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

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

[...]