Получить ресурс в API отдыха на основе альтернативного идентификатора - PullRequest
Новая
       14

Получить ресурс в API отдыха на основе альтернативного идентификатора

0 голосов
/ 31 октября 2018

Каким будет соглашение об API отдыха для получения ресурса на основе другого идентификатора?

Например 

GET
/resource/{id}

GET
/resource/{guid}

Так как это можно рассматривать как дублирующий ресурс, и настройка маршрутов для этого может быть проблемой, какая альтернатива тогда будет следовать рекомендациям остальных API?

Может

/ ресурсы /? = {GUID} * GUID * 1010

или

/ ресурсы / справ / {GUID}

или что-то еще?

Ответы [ 2 ]

0 голосов
/ 31 октября 2018

Я бы обычно не дублировал конечную точку. Вопрос будет:

почему у одного клиента есть идентификатор, а у другого - идентификатор?

Какой выбор дизайна позволил этому случиться?

Я бы оставил это как одну конечную точку ресурса: 

GET
/resource/{id}

поэтому клиенты, которые получают доступ к ресурсам через свой идентификатор, будут использовать вышеуказанную конечную точку Я бы позволил клиентам, которые получают доступ к ресурсам через их guid, обменивать то, что у них есть (guid) на то, что им нужно (id): 

GET
/id/{guid}

Вышеприведенное возвращает идентификатор ресурса для данного идентификатора ресурса. Затем клиент может вызвать конечную точку основного ресурса с только что полученным идентификатором: 

GET
/resource/{id}

но в конечном итоге я хотел бы выяснить, почему некоторые клиенты используют guid, а не id, и изменить его так, чтобы все клиенты обращались к API одинаково.

0 голосов
/ 31 октября 2018

Краткий ответ

Вы можете использовать как /resource/{id}, так и /resource/{guid}. Многие платформы поддерживают регулярные выражения для сопоставления значений параметров пути.

Длинный ответ

REST - это архитектурный стиль , а не поваренная книга для разработки URI (см. Примечания ниже) . Он не навязывает какой-либо дизайн URI, и вам остается только выбрать URI, которые лучше идентифицируют ваши ресурсы.

Следует помнить следующее: совершенно нормально иметь несколько сопоставлений для одной и той же сущности. И каждое отображение является ресурсом , согласно диссертации Филдинга:

Ресурс - это концептуальное отображение набора сущностей, а не сущности, которая соответствует сопоставлению в любой конкретный момент времени.

С учетом сказанного, если вы поддерживаете DELETE, важно упомянуть, как это должно работать:

4.3.5. DELETE

Метод DELETE запрашивает, чтобы исходный сервер удалил связь между целевым ресурсом и его текущей функциональностью. По сути, этот метод аналогичен команде rm в UNIX: он выражает операцию удаления в сопоставлении URI исходного сервера, а не ожидание удаления ранее связанной информации. [...]

Примечание 1: Синтаксис URI определен в RFC 3986 . Как правило, путь организован в иерархической форме (с сегментами, разделенными /) и может содержать неиерархические данные в компоненте запроса (начиная с ?).

Примечание 2: Архитектурный стиль REST описан в главе 5 диссертации Роя Т. Филдинга и определяет набор ограничений, которым должен следовать приложения, которые следуют такой архитектуре. Однако в нем ничего не говорится о том, какими должны быть URI.

Примечание 3: Примеры популярной статьи , написанной Мартином Фаулером, объясняющей модель, определенную Леонардом Ричардсоном , предлагают структура URI, которая выглядит дружелюбной и легко читаемой.

...