Что такое способ REST для обновления записи без первичного ключа? - PullRequest
Новая
       29

Что такое способ REST для обновления записи без первичного ключа?

0 голосов
/ 04 мая 2019

Я создал REST API. Согласно моей схеме, мы должны хранить уровень сахара в крови пользователя на ежедневно .

Проблема:

  • Я хочу использовать одну конечную точку для операций вставки и обновления
  • Я не хочу использовать первичный ключ ресурса blood-sugar в URI, потому что я хочу сохранить только последнее значение для одного дня .

Например, если я сделаю этот звонок 

POST https://{host}/users/1/blood-sugar/

{
    "measureDate": "2019-05-04",
    "bloodSugarLevel": 86
}

Он создаст ресурс blood-sugar, а база данных назначит и ID (скажем, ID=333)

Пока все в порядке.

Затем я хочу сделать второй запрос с той же датой, но с другим уровнем сахара в крови. В результате я хочу, чтобы бэкэнд должен был найти предыдущий ресурс blood-sugar (с ID=333) и обновить поле bloodSugarLevel, потому что у нас уже есть запись на этот день (2019-05-04). Я не хочу отправлять ID=333 в теле запроса или URI. 

POST https://{host}/users/1/blood-sugar/

{
    "measureDate": "2019-05-04",
    "bloodSugarLevel": 105 # only this value is different
}

Мой вопрос:

Есть ли способ достичь этого (или аналогичного) результата с помощью REST? Вы можете предложить мне изменить VERB или URI или тело запроса.

Примечание: Если бы я делал это с WCF или чем-то подобным, только один метод мог бы удовлетворить все мои требования. Например: CreateOrUpdateBloodSugarLevel(int userId, DateTime measureDate, int bloodSugarLevel)

Спасибо.

1 Ответ

2 голосов
/ 05 мая 2019

Есть ли способ достичь этого (или аналогичного) результата с помощью REST?

Хорошо просто отправить обновленное значение в ту же конечную точку.

Подумайте, как бы вы сделали это во всемирной паутине. Вы заходите на веб-сайт и загружаете некоторую форму, содержащую текстовое поле для даты, текстовое поле для bloodSugarLevel и кнопку отправки. Это отправит сообщение на веб-сервер, и ваш браузер получит ответ.

Обратите внимание, что нам, как клиенту, нас действительно не волнует, добавляет ли сервер новое сообщение в список, или помещает сообщение в карту, или делает что-то умное с RDBMS или графической базой данных. Это детали реализации; Часть единого интерфейса заключается в том, что интерфейс означает, что клиентам (и общим компонентам) действительно не нужно знать, что происходит.

Еще один протокол приложения, который мог бы работать, - это рассматривать bloodSugarLevel как документ, который пользователи могут редактировать локально. Таким образом, клиент может просто использовать любой редактор с поддержкой HTTP для правильной работы. 

GET /users/1/blood-sugar/

200 OK

{
    "measureDate": "2019-05-03",
    "bloodSugarLevel": 90
}

PUT /users/1/blood-sugar/
{
    "measureDate": "2019-05-04",
    "bloodSugarLevel": 86
}

204 No Content

PUT /users/1/blood-sugar/
{
    "measureDate": "2019-05-04",
    "bloodSugarLevel": 105
}

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

Семантически, PUT означает «upsert», но базовая реализация не обязательно должна быть upsert. Мы только обещаем семантику, которую может ожидать клиент.

...