что должен ответить REST full api для патча http методом? - PullRequest
Новая
       8

что должен ответить REST full api для патча http методом?

0 голосов
/ 13 февраля 2019

У меня есть ресурс заказа на сервере.URL выглядит как http://example.net/order/1 метод get, указанный выше, URL возвращает весь объект заказа, например 

    {
    "orderNo": "1",
    "status": "order place",
    "orderTimestamp": "2018-11-22 14:28:12",
   "invoiceAddress": {
        "salutation": "M",
        "firstName": "Dieter",
        "lastName": "Wolf",
        "companyName": "",
        "street": "Michaelkirchstr.",
        "houseNo": "16",
        "zipCode": "31604",
        "city": "Raddestorf",
        "countryIsoCode": "DEU",
        "phone": "05763 82 60 80",
        "email": "DieterWolf@armyspy.com"
    },
    "deliveryAddress": {}
    "items": [
        {
            ...
        }
    ],
    "returnItemsDetails": []
}

Теперь я хочу предложить метод исправления для того же API, чтобы можно было обновить / добавить несколько деталей, таких какадресс доставки.Чтобы обновить детали заказа, можно запросить следующий запрос с помощью метода http patch для того же заказа url 

{
    "deliveryAddress": {
        "deliveryType": "CUSTOMER",
        "salutation": "M",
        "firstName": "Dieter",
        "lastName": "Wolf",
        "companyName": "",
        "street": "Michaelkirchstr.",
        "houseNo": "16",
        "zipCode": "31604 ",
        "city": "Raddestorf",
        "countryIsoCode": "DEU",
        "phone": "05763 82 60 80",
        "email": "DieterWolf@armyspy.com"
    }
}

Мой вопрос: что должно быть в ответе на запрос исправления в соответствии со стандартом REST?или есть ли какой-нибудь документ, в котором я могу найти данные и формат ответов для REST api.

Ответы [ 2 ]

0 голосов
/ 13 февраля 2019

Мой вопрос: что должно быть в ответе на запрос исправления в соответствии со стандартом REST?или Есть ли какой-нибудь документ, в котором я могу найти данные и формат ответа для REST API.

В соответствии с RFC 5789 успешный ответ может возвращать любые коды успеха (т.е. 200 или 204).В идеале он также должен содержать заголовок ETag, чтобы клиенты могли отслеживать текущую версию для возможных последовательных запросов (которая в основном используется для оптимистической блокировки состояния ресурсов).

В спецификации образец 204 No Content представлен в видеПатч состоит, в общем, из набора инструкций, рассчитанных клиентом, которые сервер должен применить для преобразования целевого ресурса в желаемое состояние.Таким образом, клиент заранее знает, как должен выглядеть конечный результат, и поэтому серверу не нужно информировать об этом клиента.

В случае, если вы хотите вернуть ответ 200 OK, я предлагаю вернуть представление, предложенноеAccept заголовок запроса, выдаваемый клиентом (согласование типа контента), чтобы не вызывать у клиента какой-либо предопределенный формат мультимедийного типа, который он может не понять, или не использовать другие возможности.

Если вам необходимо применитьнепредсказуемые изменения ресурса, т. е. на основе некоторых вычислений, выполненных на стороне сервера или включающих полезную нагрузку для определенного предопределенного элемента (как, вероятно, сделано в вашем примере), RFC 5789 прямо заявляет, что вместо PUT следует использовать POSTили PATCH.Также обратите внимание, что вы могли бы поддерживать формат application/merge-patch+json media и его семантику, определенную в RFC 7386 , чтобы выдать такой (примерный) текст как полезную нагрузку для запроса PATCH и, вероятно, достичь желаемого результата.

0 голосов
/ 13 февраля 2019

Мой вопрос: что должно быть в ответе на запрос исправления в соответствии со стандартом REST?или Есть ли какой-нибудь документ, в котором я могу найти данные ответа и формат для REST api.

Патч определен в RFC 5789 .Раздел 2 демонстрирует, что одна возможность состоит в том, что вы вернете обновленное представление ресурса:

Ответ на этот метод можно кэшировать только в том случае, если он содержит явную информацию о свежести (например, заголовок Expires или «Cache»).-Контроль: директива max-age "), а также заголовок Content-Location, соответствующий Request-URI, указывая, что тело ответа PATCH является представлением ресурса.

Но я не смогнайти спецификацию для более общего случая.Так что я бы посоветовал интерпретировать спецификации из RFC 7231 для PUT и DELETE, а также к PATCH

представление статуса действия

...