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

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

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

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

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

Спасибо


rest asp.net-core-webapi httpresponse httpresponsemessage http-response-codes
person Fabricio Rodriguez    schedule 12.09.2018    source источник

Ответы (2)


arrow_upward
1
arrow_downward

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

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

Однако есть способ превратить это во что-то более похожее на REST.

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

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

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

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

Я бы посоветовал не менять цель 207 Multi-Status.

person Evert    schedule 12.09.2018
comment
Спасибо, Эверт, мне очень нравится твой подход к этой проблеме. Да, я согласен с вами в том, что эта конкретная конечная точка, вероятно, не является RESTful с точки зрения того, что она выполняет как INSERTS, так и UPDATES одновременно. Но если посмотреть на это под вашим углом, я полагаю, что тогда это было бы RESTful, и ответы 200 OK или 204 NO CONTENT были бы идеально подходящими! - person Fabricio Rodriguez; 12.09.2018

arrow_upward
1
arrow_downward

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

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

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

В этом документе также указывается следующее:

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

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

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

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

[...]

person cassiomolin    schedule 12.09.2018
comment
Спасибо, Кассио. Да, ваш ответ определенно имеет смысл, и я даже не знал, что было 207 ответов. Я выбрал решение Эверта, потому что это казалось наиболее правильным подходом в данной ситуации, но я обязательно учту ваше. Еще раз спасибо! - person Fabricio Rodriguez; 12.09.2018