PATCH vs POST - Счетчик приращений - PullRequest
Новая
       5

PATCH vs POST - Счетчик приращений

0 голосов
/ 21 сентября 2018

Два вопроса о приращении одного значения в режиме Restful

Допустим, у нас есть следующая таблица. 

public class EmployeeStatistics   
{      
    public int Id { get; set; }
    public int EmployeeId { get; set; }
    public int CallsMade { get; set; }
    public int CallsRecieved { get; set; }
}

Вопрос № 1

Какой будет правильный формат для увеличения поля CallsMade?

A: api/EmployeeStatistics/AddCallMade/EmpId/{empId}

B: api/EmployeeStatistics/EmpId/{empId}/AddCallMade

Вопрос № 2

POST или PATCH?

В Интернете существуют противоречивые ответы на этот вопрос.

Хотя PATCH используется для замены определенных значений, я не собираюсь указыватьполезная нагрузка, содержащая конечное значение, скорее я хотел бы вызвать событие на стороне сервера, которое увеличивает указанное значение и возвращает код состояния 200 по завершении.

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

Все ответы и мнения приветствуются, спасибо заранее.

1 Ответ

0 голосов
/ 21 сентября 2018

POST или PATCH?

«Зависит». PATCH , как и PUT , описывает изменение представления в независимом от домена виде.По сути, вы говорите серверу «изменить вашу копию ресурса так, чтобы она выглядела как this .

Большинство форматов PATCH не предлагают операцию« приращения »;get - это set или replace семантика (точно так же, как и для PUT). Выраженная в JSON PATCH, вы обычно видите операцию, подобную 

{ "op": "replace", "path": "/CallsMade", "value": 42 }

Или, если вы пытаетесьчтобы гарантировать отсутствие утраченных правок 

{ "op": "test", "path": "/CallsMade", "value": 41 }
{ "op": "replace", "path": "/CallsMade", "value": 42 }

PATCH также имеет семантику атомарных изменений

Сервер ДОЛЖЕН применять весь набор изменений атомарно и никогда не предоставлять (например, в ответв GET во время этой операции) частично измененное представление.

Так что если вы не можете на самом деле гарантировать, что изменения будут все или ничего, если вы не можете поместить все измененияв одну «транзакцию», тогда PATCH - неправильная идея.

Тем не менее, все, что вы можете сделать с PATCH, также можно сделать с помощью POST - POST просто предлагает меньше гарантий.

Что быправильный формат для увеличения поля CallsMade?

PATCH, как PUT и DELETE, описывает изменение представления ресурса.Обычный ритм будет выглядеть примерно так: 

GET /X
(edit)
PATCH /X

REST не имеет значения, какое написание используется для ваших идентификаторов, поэтому все следующие параметры одинаково приемлемы 

api/EmployeeStatistics/AddCallMade/EmpId/{empId}
api/EmployeeStatistics/EmpId/{empId}/AddCallMade
api/EDA9E9D4-EC6D-4884-91A6-F15BCE88D060

Мы обычно используем сегменты пути для иерархических данных, поэтому вы можете использовать целевой URI, например, если потребители ожидали отредактировать всю сущность EmployeeStatistic 

api/EmployeeStatistics/{empId}

или целевой URI, как этот, если выхотел предоставить ресурс, ограниченный только информацией, связанной с совершенными вызовами 

api/EmployeeStatistics/{empId}/callsMade

результаты на кэшах вашего потребителя не совсем совпадают, поэтому вам нужно будет тщательно обдуматьзерно ваших ресурсов.

С POST ... ну, с POST вы можете делать практически все;это карта без HTTP-методов, которая выходит из тюрьмы.По-прежнему существуют последствия для кэширования, но нет ничего принципиально неправильного в том, чтобы иметь один ресурс, который может увеличивать callMade любого сотрудника.

...