REST api - обновление указанного ресурса c с помощью PATCH без включения указанного идентификатора ресурса c в запрос

Question

Я разрабатываю REST API для управления машинами компании, где сотрудники берут машины, и go в поездках. У аттракционов есть свойство под названием isActive.

Когда они заканчивают sh поездку, свойство isActive должно быть установлено на false.

Как работает мой API в настоящее время, это то, что конечная точка для завершения (PATCH HTTP-запрос) количество поездок равно /api/v1/rides.

. Пользователь отправляет запрос PATCH с токеном JWT, и API определяет из контекста HTTP, какой пользователь это, находит индивидуальную поездку, связанную с пользователем. обновляет свойство isActive до false и обновляет короткий комментарий типа string, который вводит пользователь.

Это приемлемо?

Каждый найденный мной источник утверждает, что конечная точка должна выглядеть примерно так: /api/v1/rides/{rideId}, но я не понимаю, почему это было бы необходимо в этом контексте, потому что это потребовало бы больше работы на стороне интерфейса .

Answer 1

Это приемлемо?

Вероятно, нет

PATCH /api/v1/rides

- это запрос на изменение ресурса /api/v1/rides; то есть тот же ресурс, который вы запрашиваете при отправке запроса GET /api/v1/rides. Если вы намерены вместо этого изменить какой-либо другой ресурс, то ресурс, который вы намереваетесь изменить, должен быть целевым URI.

Потенциальная проблема заключается в следующем: компоненты общего назначения HTTP думают, что все ресурсы понимают просит так же. Это REST-ограничение интерфейса «самоописательные сообщения» на работе. Когда вы рекламируете, что ваш ресурс поддерживает PATCH, мой сторонний браузер / spider / cache / proxy может предположить, что PATCH означает то же самое для вашего ресурса, что и любой другой ресурс в Интернете.

Когда что-то идет не так дорого, потому что ваш ресурс использовал семантику, отличную от стандартной, это на вас, а не на клиенте.

PATCH означает «применить эти изменения к ресурсу, определенному целью URI». Если вы хотите применить изменения к другому ресурсу, вам следует указать этот идентификатор вместо этого.

Если вы делаете что-то нестандартное, то вам, вероятно, следует использовать POST, а не PATCH, так как маркер метода в запросе. См. Fielding 2009 :

POST служит многим полезным целям в HTTP, включая общую цель «это действие не стоит стандартизировать».