Потребляя REST API конечной точки из ресурса ID

Question

давайте рассмотрим следующий поток к RESTfull API:

API root  
     | 
     v 
    user list  
     | 
     v 
    user details 
     | 
     v 
    user messages 

Предположим, что у меня есть клиент, использующий API, и я хочу получать сообщения от пользователя с ID 42. Из того, что я изучал, мой клиент не должен знать, как «строить» URL-адреса, и он должен следовать ссылкам, предоставленным API.

Как мне сделать, чтобы получать сообщения для пользователя с идентификатором 42?

Единственный способ, по которому я могу думать, - это «прогулка» по всему API от его корневых до пользовательских сообщений, что для меня не очень красиво или эффективно.

Например:
1 - GET/и получить ссылку на список пользователей
2 - GET/пользователь/ID = 42 и получить ссылку на детали пользователя с ID 42
3 -? GET/user/42/и получить ссылку на пользователя 42 Список сообщений
4 - GET/user/42/messages/и, наконец, получить сообщения пользователя

Я получил что-то не так? Правильно ли это в соответствии с документом Роя Филдинга? Или это просто предположить, что URL-адрес сообщения «/ user/{id}/messages /» и сделать запрос напрямую?

Answer 1

Я верю, какова ваша настоящая проблема, если вы идете о внедрении HATEOAS или нет. Теперь, поскольку это неотъемлемая часть спецификаций REST, рекомендуется, чтобы каждый объект имел ссылку на его дочерний объект, который он охватывает. В вашем случае API ROOT должен показывать список пользователей, у каждого «пользователя» есть ссылка (/ root/users/{id}) на соответствующие данные пользователя. И каждый объект данных пользователя будет содержать ссылку на список «сообщений» (/ root/users/{id}/messages), которые, наконец, inturn также включают ссылку на фактическую информацию сообщения (/ root/users/{ ID}/сообщения/{MessageId}). Эта концепция чрезвычайно полезна (и, следовательно, является частью спецификаций), потому что клиенту не нужно знать URL-адрес, где находится ваша организация. Например, если ваши пользователи были на http://users.abc.com/rest/users/ {id}, но ваши сообщения были на http://messages.abc.com/rest/ {userId}/messages/{messageId}, пользовательский объект, который включает в себя список «сообщений», уже имеет ссылку, вложенную, чтобы указать на правильный ресурс на другом сервере.

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

В конце концов, все зависит от того, насколько близки вы хотите, чтобы ваши реализации REST соответствовали спецификациям и каким клиентам вы будете иметь. Мои 2 цента были бы: если у вас есть время, реализуйте REST с HATEOAS и гордитесь этим :). Там есть библиотеки, которые сделают эту реализацию (HATEOAS) несколько прозрачной для вас реализацией REST (я считаю, что у весны есть одна, хотя и не очень зрелая. Вы можете посмотреть на нее here). Если вы похожи на меня и у меня мало времени на этот маршрут, я думаю, что вы можете продолжить обычную реализацию REST без HATEOAS, и ваши клиенты все равно будут в порядке (или я надеюсь!)

Надежда это помогает!

Answer 2

Используйте URL-шаблоны в корне API. Пусть клиент использует root API во время выполнения. Он должен искать шаблон URL с именем «user-messages» со значением «/ user/{userid}/messages /». Затем позвольте клиенту заменить «42» на «{userid» »в шаблоне и сделать GET на результирующем URL-адресе. Вы можете добавить столько шаблонов URL, которые вы хотите для всех необходимых, часто используемых, прецедентов.

Разница между этим решением и «классическим» веб-API заключается в позднем связывании URL-адресов: клиент читает корень API с его шаблонами во время выполнения - в отличие от компиляции клиента со знанием шаблонов URL-адресов.

Посмотрите на типе HAL медиа для некоторой информации о шаблонах URL: http://stateless.co/hal_specification.html

Я написал эту часть здесь некоторое время назад, чтобы объяснить преимущество гипермедиа: http://soabits.blogspot.dk/2013/12/selling-benefits-of-hypermedia.html

Answer 3

Я нашел эту статью о взломе urls: Avoid hackable URLs.
В разделе комментариев есть очень интересная дискуссия по теме этого вопроса.