Имена ресурсов Rest API с несколькими идентификаторами - PullRequest
Новая
       29

Имена ресурсов Rest API с несколькими идентификаторами

2 голосов
/ 10 июля 2019

После прочтения:

https://restfulapi.net/resource-naming/

У меня есть вопрос о пересмотре ссылок на документы в коллекциях, когда документ имеет несколько уникальных идентификаторов.

В связанном материале примердается:

Мы можем идентифицировать один ресурс «клиента», используя URI «/customers/ndomcustomerIdcaststially.

или 

http://api.example.com/device-management/managed-devices/{device-id}
http://api.example.com/user-management/users/{id}
http://api.example.com/user-management/users/admin

И мой пример: 

http://myserver/api/courses/{id}

У которого есть аналог функции js Express: 

app.get('/api/courses/:id', (req, res) =>...

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

Например, ID1 & ID2.

Как бы я кодировал это в экспрессе и как мне написать URL?

Такесли мне нужно, чтобы два API были: 

http://myserver/api/courses/{id1}
http://myserver/api/courses/{id2}

Если я предоставлю две подпрограммы Express: 

app.get('/api/courses/:id1', (req, res) =>... 
app.get('/api/courses/:id2', (req, res) =>...

И ID1, и ID2 имеют одинаковый тип (например, числа).Как REST API различает эти два?

Ответы [ 2 ]

3 голосов
/ 10 июля 2019

REST не заботится об написании идентификаторов вашего ресурса. Соглашения, подобные описанным в https://restfulapi.net/resource-naming/, примерно аналогичны соглашениям о кодировании написания имен переменных.

С точки зрения клиента REST, /api/courses/X и /api/courses/Y - это разные ресурсы - эти ресурсы могут совместно использовать одно и то же базовое представление (поскольку они построены из одних и тех же базовых данных) , но это проблема реализации сервера.

Написание URI ограничено только RFC 3986 . 

/api/courses?id1=12345
/api/courses?id2=67890

Это совершенно разумный выбор. Одним из потенциальных преимуществ является то, что HTML включает стандарт для создания шаблонов URI с параметрами запроса. Потенциальным недостатком является то, что относительное эталонное разрешение обрабатывает неиерархические данные в части запроса иначе, чем иерархические данные в сегментах пути. 

/api/courses/id1/12345
/api/courses/id2/67890

Совершенно разумный выбор с противоположным компромиссом сверху. 

/api/courses/id1=12345
/api/courses/id2=67890

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

Как и шаблоны URI , они, вероятно, будут выглядеть как 

/api/courses/id1={id}
/api/courses/id2={id}

Но там, где у вас есть поддержка шаблонов URI 4-го уровня, вы можете использовать 

 /api/courses/{/ids*}

Другой возможностью будет использование написания, основанного на «матричном параметре», например 

/api/courses;id1=12345
/api/courses;id2=67890

Опять же, это дает вам другой набор компромиссов читаемости, поддержки шаблонов, поддержки относительного разрешения и т. Д.

См. Также Стефан Тилков - ОТДЫХ: Я не думаю, что это означает то, что вы думаете, это делает .

0 голосов
/ 10 июля 2019

Чтобы узнать, какое поле отправляется, необходимо ввести другое различие в URL-адресе либо в пути, либо в качестве параметра запроса. По умолчанию будет для поля № 1, а другой для поля № 2 

app.get('/api/courses/:id1', (req, res) =>... 
app.get('/api/courses/other-key/:id2', (req, res) =>...
...