Получить ресурс в покое api на основе альтернативного идентификатора

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

Например

GET
/resource/{id}

GET
/resource/{guid}

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

Может быть

/ resources /? guid = {guid}

или

/ ресурсы / руководство / {руководство}

или что-то другое?

2
0
260
2
Перейти к ответу Данный вопрос помечен как решенный

Ответы 2

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

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

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

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

Вы должны иметь в виду: совершенно нормально иметь множественные сопоставления для одного и того же объекта. И каждое отображение - это ресурс, согласно диссертации Филдинга:

A resource is a conceptual mapping to a set of entities, not the entity that corresponds to the mapping at any particular point in time.

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

4.3.5. DELETE

The DELETE method requests that the origin server remove the association between the target resource and its current functionality. In effect, this method is similar to the rm command in UNIX: it expresses a deletion operation on the URI mapping of the origin server rather than an expectation that the previously associated information be deleted. [...]


Note 1: The URI syntax is defined in the RFC 3986. As general rule, the path is organized in hierarchical form (with segments separated by /) and can contain non-hierarchical data in the query component (starting with ?).

Note 2: The REST architectural style is described in the chapter 5 of Roy T. Fielding's dissertation and it defines a set of constraints that must be followed by the applications that follow such architecture. However it says nothing about what the URIs must be like.

Note 3: The examples of a popular article written by Martin Fowler explaining a model defined by Leonard Richardson suggest a URI structure that looks friendly and easy to read.

Ответ принят как подходящий

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

why does one client have an id while another has a guid?

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

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

GET
/resource/{id}

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

GET
/id/{guid}

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

GET
/resource/{id}

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

Я не уверен, что понимаю ваши рассуждения / id / {guid} vs / resource / {id}

mko 31.10.2018 14:28

Другие вопросы по теме