В контексте RESTful API, как правильно использовать UPDATE / DELETE ресурс, к которому нужно применить фильтр?

Question

Если у меня есть следующий случай:

class Car
   int id
   int owenerId
   string color
   string model
   Set<Key> keys

class Key
   int id
   carId
   ownerId

и странный бизнес-случай, когда автомобиль однозначно идентифицируется по владельцу, цвету и модели, как правильно указать go о моем RESTful API

GET / автомобили / владельцы / {ownerId}? Color = black & model = BMW

, которые были бы моим GET-запросом, учитывая, что владелец - это ресурс, а цвет и модель - свойства ресурса автомобиля

У меня также есть идея, как может выглядеть мой POST

POST /cars/owners/{ownerId}
{
    "color": "black",
    "model": "BMW",
    "keyIds" : [123,234,546]
}

Как мне go узнать о моих запросах PUT / PATCH / DELETE, если я хочу манипулировать коллекцией ключей. Является ли этот PUT действительным, следуя способу RESTful

PUT /cars/owners/{ownerId}?color=black&model=BMW
{
    "keyIds": [344,3453]
}

Что если мне придется использовать POST для обновления моего ресурса по какой-либо причине (например, некоторые версии JAX-RS не имеют аннотации PATCH)

Я не могу go / автомобили / владельцы / {ownerId}? Color = black & model = BMW / update, так как бы мне go о моем запросе

Неужели я понял, что весь REST-объект совершенно неправильный?

Answer 1

Если оставить в стороне, что это немного странно, но вы говорите, что ваш первичный ключ является комбинацией владельца / цвета и модели.

Основной способ идентификации это в вашем REST API через URL со следующим шаблоном:

/cars/owners/{ownerId}?color=black&model=BMW

Тогда я бы предположил, что запрос PUT использует идентичный URL:

/cars/owners/{ownerId}?color=black&model=BMW

Как бы я go о моих запросах PUT / PATCH / DELETE, учитывая, что я хочу манипулировать коллекцией ключей. Является ли этот PUT действительным, следуя способу RESTful

Указанный вами пример c не подходит. PUT должен полностью заменить состояние цели, и если вы укажете только keyIds и обновите только это свойство, PATCH может быть более уместным.

Что если мне придется используйте POST для обновления моего ресурса по любой причине (например, некоторые версии JAX-RS не имеют аннотации PATCH)

Я не могу go / cars / owners / {ownerId}? color = black & model = BMW / обновить, так как бы я go о моем запросе

Я не до конца понимаю, в чем здесь проблема. Вы можете сделать запрос POST, как захотите.

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

Прежде всего, похоже, что вы у вас действительно есть id в вашем классе автомобилей, так что вы можете упростить себе задачу, просто используя:

/car/{id}

Это также означает, что ваши URL будут стабильными, если владелец сменится. Параметры запроса чаще используются для фильтрации / поиска и реже для идентификации определенного c ресурса, поэтому вот еще один шаблон URL, который будет более понятным:

/owner/{ownerId}/cars/BMW/black

Здесь возникает вопрос, что если у владельца есть 2 черных BMW, поэтому это должен быть уникальный ключ.

Как правило, это шаблоны взаимодействия с ним:

GET /owner/{ownerId}/cars/BMW/black <- retrieve current state
PUT /owner/{ownerId}/cars/BMW/black <- replace current car, or create a new car
DELETE /owner/{ownerId}/cars/BMW/black <- remove car
PATCH /owner/{ownerId}/cars/BMW/black <- partially update the car

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