Подход RESTful для обновления ресурса и создания связанных объектов

Я разрабатываю API в стиле REST для службы, обеспечивающей анализ клинических данных. API позволяет пользователю создавать ресурс пациента. Этот ресурс предоставляет входные данные для анализа на стороне сервера.

Создание пациента не является ни безопасным, ни идемпотентным (сервер присваивает идентификатор), поэтому используется POST, POST Patients

Ресурс пациента может быть большим, поэтому он имеет подресурсы, например. Лекарства, которые можно обновить. Обновление лекарств является идемпотентным, так как весь набор лекарств будет заменен, поэтому используется PUT.

Клинический анализ запускается запросом POST /Patients/{patientId}/analysisResults . В качестве альтернативы пользователь может запросить возврат результатов анализа в ответ на запрос POST /Patients; это экономит дополнительный HTTP-трафик.

Моя проблема в следующем; пользователи хотят, чтобы результаты анализа были включены в ответ на обновление (PUT) для Patient/Medications — это понятно, поскольку они не хотят делать второй запрос для получения результатов. Таким образом, PUT Patient/Medications будет идемпотентным по отношению к ресурсу Patient, но не ко всем ресурсам, поскольку будет создан новый подресурс analysisResults. Нужно ли мне:

  • а) Включите это с помощью PUT.
  • б) Включите это с помощью POST.
  • c) Настаивать на том, что для создания новых результатов анализа требуется отдельный вызов, даже если это увеличит общее время отклика для конечного пользователя?

person Alistair77    schedule 19.10.2012    source источник
comment
Создание нового подресурса analysisResults не обязательно означает, что запрос не является идемпотентным. Если несколько запросов PUT с одними и теми же входными данными создают один и тот же подресурс, вызов по-прежнему является идемпотентным, но небезопасным, однако, если вызов создает новый подресурс для каждого PUT с одними и теми же данными, тогда он неидемпотентный и также небезопасный. См. sureshkk.wordpress.com/2009/04/22/. чтобы узнать больше о разнице между безопасностью и идемпотентностью.   -  person Suresh Kumar    schedule 19.10.2012


Ответы (1)


Вариант C, если вы хотите оставаться RESTful.

Варианты A и B, скорее всего, ослабят свойства, которые REST призван дать вам, кэширование — это то, что сразу приходит на ум.

Если это основано на HTML, ответ будет содержать ссылку на ресурс analysisReport, чтобы пользователь мог направить приложение куда-нибудь полезное.

person Michael Brown    schedule 19.10.2012