Покойный способ определить ресурс и его тип - PullRequest
Новая
       19

Покойный способ определить ресурс и его тип

0 голосов
/ 12 июня 2019

У меня типичная проблема дизайна, и мне нужно решить ее RestFul способом.Не в состоянии найти идеальное решение.Допустим, у нас есть ресурс «средство передвижения», и мы хотим поддерживать операции CRUD на том же.Рассмотрим случай с автомобилем CREATE. 

POST /vehicle
{
   "type": "sedan",
   "params": {
      "p1":"v1",
      "p2":"v2"
   }
}

Теперь может быть много разных типов транспортных средств (например, седан, хэтчбек, 2-х колесный и т. Д.).Я хочу определить API, который может дать мне список всех типов транспортных средств.Я не уверен, как определить ресурс для того же.Некоторые варианты, которые я могу придумать:

GET /vehicle-types
GET /vehicle/types

Какой из перечисленных выше вариантов или других вариантов люди считают более спокойным?Выходными данными здесь должен быть список всех поддерживаемых транспортных средств, например, 

["sedan", "hatchback", "2wheeler"]

Кроме того, я также хотел бы, чтобы пользователи также могли найти параметры конфигурации для типа транспортного средства.например, 

GET /vehicle/types/sedan/params (Not sure of its correct though)

В идеале должно быть указано выше: 

{ 
  "fields": [{"name":"p1", "type":"string", "required":"true"}, 
             {"name":"p2", "type":"string", "required":"false"}]
}

Каким должен быть лучший способ определения ресурсов и юрисдикций здесь?Цени любую помощь!

Ответы [ 2 ]

0 голосов
/ 13 июня 2019

Какой из перечисленных выше вариантов или других вариантов люди считают более успокоительным?

REST не имеет значения, какое правописание вы используете для идентификаторов ресурсов.

RFC 3986 описывает пути следующим образом:

Компонент пути содержит данные, обычно организованные в иерархической форме, которые наряду с данными в неиерархическом компоненте запросов (раздел 3.4), служит для идентификации ресурса в рамках схемы URI и полномочий по присвоению имен (если таковые имеются).

Поэтому во многих проектах мы выбираем иерархию идентификатора , которая соответствует иерархии resource , что позволяет нам делать такие вещи, как использование точечных сегментовчтобы легко вычислить идентификаторы для других близлежащих ресурсов. 

/vehicle/types/sedan/params + .. -> /vehicle/types/sedan
/vehicle/types/sedan/params + ../.. -> /vehicle/types
/vehicle/types/sedan/params + ../../hatchback -> /vehicle/types/hatchback
/vehicle/types/sedan/params + ../../.. -> /vehicle
... and so on.

Но нет ничего плохого в том, что вы решили использовать другое соглашение.Машины не заботятся.

В Интернете мы часто использовали параметризованные идентификаторы - обработка формы HTML определяет, как принимать входные данные формы и кодировать их в строку запроса. Шаблоны URI являются продолжением этой идеи в более широком диапазоне шаблонов, как в частях path, так и query.

0 голосов
/ 12 июня 2019

Если вы хотите пройти через удобный для пользователя путь, то я думаю, что упомянутые вами варианты кажутся хорошими, GET / транспортное средство / типы GET / транспортное средство / типы / седан / params Но это не RESTful способ, так как типы и параметры не являются ресурсом на вашем конце. Я предполагаю, что изменение модели ресурса здесь не вариант.

Итак, если вы хотите решить эту проблему в соглашении REST, то я бы предложил использовать поле param для указания в аргументе запроса, который будет указывать поле, которое нужно пользователю

GET / vehicle? Field = type Результат: ["седан", "хэтчбек", "2wheeler"]

GET / vehicle? Field = param Результат: [{"name": "p1", "type": "string", "required": "true"}, {"name": "p2", "type": "string", "required": "false"}]

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

GET / vehicle? Type = 'sedan' & field = param

Вы можете иметь логику для удаления дублирующихся элементов, если нужно

Подробнее: Смотрите раздел Частичный ответ, https://developers.google.com/drive/api/v3/performance

...