REST - поддержка нескольких возможных идентификаторов

Question

Для сайта, над которым я работаю, мы улучшаем наши URL-адреса для одного типа ресурсов - в частности, отступая от числовых идентификаторов к уникальным описательным строкам. Аналогичным примером может быть переход от идентификации пользователей по числовому идентификатору базы данных для идентификации их по имени пользователя (а не в нашем конкретном случае, но аналоговом). Таким образом, URL, чтобы получить доступ к информации пользователя, используемый выглядеть следующим образом:

/users/48573 

И теперь, похоже,

/users/thisisausername. 

Единственная проблема заключается в том, что нам все еще нужно, чтобы иметь возможность получать их через численные идентификаторы как-то , для устаревших потребителей API. Нам не нужны сами URL-адреса REST для перенаправления (например, /users/48573 не следует перенаправлять на /users/thisisausername), нам просто нужен метод для получения правильных данных с использованием старого идентификатора. Решение должно либо предоставить альтернативный способ доступа к информации пользователя (который удобно включает в себя новый идентификатор, имя пользователя) по идентификатору, либо получить доступ только к имени пользователя по идентификатору. Возможными решениями могут быть:

• Использование узла для указания некоторого альтернативного способа идентификации, например. /users/byid/48573
• Использование параметра запроса для указания некоторого альтернативного способа идентификации, например. /users/48573?fetchby=id или /users/48573?byid=true
• Рассмотрение имени пользователя по-одному в качестве другого ресурса, например. /identifiers/username/48573

Какой из них (если есть) является самым близким к надлежащему REST? Как бы вы справились с этой проблемой?

Answer 1

Ваш первый вариант, вероятно, лучший.

Поиск пользователей по ID:

/users/id/48573 

Поиск пользователей по короткому имени:

/users/name/thisisausername 

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

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

/users?id=48573 
/users?name=thisisausername 

Я думаю, что первый выглядит немного чище и более удобным для чтения.

Answer 2

Я бы рассмотреть квалификационные строки с дополнительным суффиксом:

/users/48573/id 

/users/48573/name 

Если вы получите строку без суффикса:

/users/48573 

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

Если вы только получить действительное удостоверение личности, но не имя, то это поиск по ID эквивалентно:

/users/48573/id 

Если вы только получить имя тогда это поиск по имени, эквивалентном:

/users/48573/name 

Если вы можете получить значение по ID или имя, то вы возвращаете ошибку в 300 Ответную ссылки на оба идеи! клиент:

/users/48573/id 

/users/48573/name 

Наследственные потребители продолжают работать «как есть», за исключением случайного появления повторяющихся пар ID/name, где они получают новую ответную ошибку 300.

Answer 3

Ваш API не является RESTful, если это проблема. До quote Roy Fielding:

REST API не должен определять фиксированные имена ресурсов или иерархии (очевидное соединение клиента и сервера). Серверы должны иметь свободу контролировать свое пространство имен. Вместо этого разрешите серверам указывать клиентам, как создавать соответствующие URI, например, в HTML-формах и шаблонах URI, определяя эти инструкции в типах медиа и связных отношениях. [Сбой здесь означает, что клиенты принимают структуру ресурсов из-за внеполосной информации, такой как стандарт, специфичный для домена, который является ориентированным на данные эквивалентом функциональной связи RPC].

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

Answer 4

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

Лично я планирую использовать отрезок пути префикс, ограниченную «=», как «имя =» или «электронная почта =»:

user/123456 
user/name=john.doe 
user/email=john.doe@john.doe 

Это функционально эквивалентно добавлению сегмента пути (например, " user/name/john.doe "), но мне кажется, что он более тесно связан с концептуальной моделью. Конечно, это незначительная деталь, так как API RESTful не должен указывать фиксированную структуру URI в любом случае.

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

user/name=john.doe/inbox/df87bhJXrg63 

Каркасы, как JAX-RS Явы поддерживают использование любой разделителем вы хотите:

@GET 
@Path("user/{id}") 
User getUser(@PathParam("id") UUID id); 

@GET 
@Path("user/name={name}") 
User getUserByName(@PathParam("name") String name); 

@GET 
@Path("user/email={email}") 
User getUserByEmail(@PathParam("email") String email); 

Answer 5

довольно старый вопрос, но У меня было то же самое и finnaly нашел решение: использовать регулярное выражение в вашем параметре пути.

Вот как я закодированы, что случай использования

@GET 
@Path("/{id : \\d+}") 
@Produces(APPLICATION_JSON) 
public Response getById(@PathParam("id") long id) { 
<<your code>> 
} 

@GET 
@Path("/{name}") 
@Produces(APPLICATION_JSON) 
public Response getByName(@PathParam("name") String name) { 
<<your code>> 
}