REST: Как ресурс должен быть «обновлен»?

Question

Я создаю RESTful API, где «записи» могут быть добавлены, изменены и удалены.Каждой записи автоматически назначается дата истечения срока действия, когда она создается, и она автоматически удаляется, если не обновлена ​​до этой даты.Когда запись обновляется, ей просто присваивается более поздняя дата истечения срока действия (сервер не может выбрать дату окончания срока действия).

Мой вопрос заключается в том, каким будет RESTful способ выставить «обновление».функциональность?

Несколько вариантов, о которых я подумал (хотя ни одна из них не кажется действительно правильной):

1. DELETE /api/entries/:id/expiration-date
2. PATCH /api/entries/:id с "expirationDate": null в теле (JSON)
3. PATCH /api/entries/:id с любым телом или без него
4. PUT /api/entries/:id (по существу требуется повторная отправка записи)

Примечание. В настоящее время единственными предполагаемыми потребителями API будут мои собственные клиентские приложения, но я могу сделать это в будущем.

Answer 1

Лично я бы использовал простой запрос POST, чтобы сообщить серверу о его продлении. Это не RESTful, но кажется, что это самый простой способ решить эту проблему.

Вот RESTful ответ.

REST - это отправка состояния назад и вперед между ресурсами. В этом конкретном случае немного сложно напрямую связать это с состоянием ресурса.

Лучшее, что я могу придумать при ограниченном описании, это то, что, возможно, ресурс остается активным, пока кто-то его «видел».

Это можно перевести обратно в свойство lastSeen: "date-time".

Я подозреваю, однако, что у акта продления есть особая деловая причина, и может быть лучший способ перевести эту деловую причину в состояние, подобное REST, или свойство.

редактировать

Если подумать, я бы использовал свойство lastRenewed и значение даты / времени. Это отсоединяет его от «истечения срока действия», связывает информацию с ресурсом и позволяет избежать проблемы, когда пользователю нужно установить значение null только для его немедленной замены сервером.

Answer 2

Мой вопрос заключается в том, каким был бы RESTful способ предоставить функцию «продления»?

Как бы вы предоставили эту функцию на веб-сайте?

Вы, вероятно, начнете с просмотра веб-страницы записи с помощью запроса GET, которая загрузит текущее представление страницы в локальный кэш. Вы

Когда сервер определил, что запись имеет право наОбновление, веб-страница будет включать в себя своего рода гипермедиа, позволяющую клиенту запускать протокол обновления.В этом случае вы, вероятно, не хотите, чтобы у этого обеспечения была безопасная семантика, поэтому это будет форма, использующая метод POST.Когда пользователь отправляет форму, браузер создает HTTP-запрос с правильными метаданными и данные формы, скопированные в тело запроса, как описано в правилах обработки HTML;запрос будет отправлен на URL-адрес, указанный сервером в форме form.action.

Имеет ли значение написание URL-адреса для пользователя?Не совсем, пользователь просто отправляет форму, URL - это просто непрозрачные данные.Косвенно это имеет значение из-за способа определения семантики аннулирования кэша - если мы намереваемся, что обновление должно evict ранее кэшированных представлений веб-страницы, тогда запрос на публикацию должен иметь URL-адрес самой страницы.

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

Сделайте это в машиночитаемом видеКстати, и у вас есть REST API.

PUT и PATCH работают одинаково, за исключением , что тело запроса является описанием самой страницы.Загрузите HTML-код, внесите изменения, затем либо поместите PUT нового документа полностью, либо вычислите патч-документ и отправьте его вместо этого.

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

Answer 3

Я бы использовал

PUT /api/entries/id/renew

с датой истечения в теле (или без срока действия по умолчанию). Причина в том, что истечение срока действия не относится к самому объекту; это метаданные, связанные с тем, как объект управляется вашей системой.