Как вы структурируете спокойный маршрут с несколькими ограничениями GET? - PullRequest
1 голос
/ 18 июля 2010

Предположим, вы работаете над API и вам нужны красивые URL.Например, вы хотите предоставить возможность запрашивать статьи на основе автора, возможно, с сортировкой.

Стандарт:

GET http://example.com/articles.php?author=5&sort=desc

Я полагаю, RESTful способ сделать это может быть:

GET http://example.com/articles/all/author/5/sort/desc

Я прав?Или я неправильно понял, что это за ОТДЫХ?

Ответы [ 4 ]

7 голосов
/ 18 июля 2010

Боюсь, ваш вопрос действительно не подходит для REST.С чисто теоретической точки зрения нет абсолютно никаких преимуществ или недостатков ни для одного из этих URL с точки зрения REST.На практике эти URL-адреса могут вести себя по-разному в разных кэшах, и, конечно, серверные инфраструктуры будут анализировать их по-разному.Несмотря на то, что вы слышите от разработчиков инфраструктуры, не существует такого понятия, как RESTful URL.

С точки зрения REST эти два URL являются просто идентификаторами, на которые можно ссылаться.Если вы хотите начать создавать API-интерфейсы REST, которые получат преимущества от характеристик, описанных в диссертации, вам нужно подумать о содержании, которое возвращается при разыменовании URL-адреса и о том, как этот контент связан вместе с помощью URL-адресов, встроенных в контент.

Я понимаю, что это мало поможет вам в попытке решить то, что вы считаете своей проблемой.Что я могу вам сказать, так это то, что одной из основных целей REST является обеспечение того, чтобы ваши URL-адреса полностью контролировались сервером и могли меняться, не влияя на ваши клиентские приложения.Поэтому я рекомендую выбрать любую структуру url, наиболее легко работающую с каркасом, который вы используете для обслуживания представлений ресурсов.Конечно, не обращайтесь к диссертации REST, чтобы сказать вам, каков правильный и неправильный способ форматирования ваших URL, и любой, кто скажет вам, что ваши URL не являются RESTful, запутался.Вероятно, они говорят вам о серверной платформе, которую они используют для создания интерфейсов RESTful, требуют, чтобы URL-адреса были структурированы таким образом.

Важно не то, как выглядит ваш URI, а то, что вы делаетес этим, что имеет значение.

3 голосов
/ 19 июля 2010

Использование строки запроса не более или менее RESTful, чем использование компонентов пути.Общий синтаксис URI (RFC 3986, январь 2005 г.) определяет, что они столь же важны в идентификации ресурса.Так что да, как отмечают другие, это не важно для ОТДЫХА.(Обратите внимание, что в obsoleted-by-RFC-3986 RFC 2396 строка запроса была не , определенной для идентификации ресурса, а скорее строка информации дляинтерпретируется ресурсом .)

Однако дизайн URI важен, поскольку в качестве владельца пространства имен URI (т. е. владельца доменного имени, в котором будут жить URI) * вы хотитеURI будут долгоживущими .Как говорили мудрецы ранее : классные URI не меняются!

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

Это такжеВажно отметить, что фактические URI имеют смысл только для двух сторон :

  • Серверы, которым необходимо подделать и проанализировать URI
  • Люди, которые могут видетьПроходящий URI может кое-что узнать из URI.

В отличие от этого, клиентским приложениям обычно не разрешается выполнять самоанализ URI.Таким образом, ваш выбор строк запроса и компонентов пути сводится к тому, что, по вашему мнению, вы можете прожить через десять (или 100) лет.

2 голосов
/ 18 июля 2010

Алан в основном прав, но его URL вводят в заблуждение. Я считаю, что правильные маршруты / URL должны отражать следующее поведение:

[GET] http://domain.com/articles #=> returns all articles (index action)
[GET] http://domain.com/articles/5 #=> returns article ID 5 (show action)
[GET] http://domain.com/authors/#=> returns all authors (index action)
[GET] http://domain.com/authors/5 #=> returns author ID 5 (show action)
[GET] http://domain.com/authors/5/articles OR http://domain.com/articles/authors/5 #=> depending on the hierarchy of your routes (both belong to the index action)

С уважением, DBA

2 голосов
/ 18 июля 2010

Вы в основном правы. Суть REST api в том, чтобы сосредоточиться на существительных.

Что делает существительное all в этом случае? Разве вы не ожидаете, что ваш API будет всегда возвращать все статей, если вы не отфильтруете его?

Я бы сделал sort параметрами строки запроса, далее я бы сделал все параметры фильтрации строки запроса. Если вы посмотрите, как реализован стек, когда нажимаете на ссылку «Новые» вопросы, вы получите строку запроса для фильтрации вопросов.

Так что, возможно, что-то вроде:

GET http://example.com/aritcles/authors/5?sort=desc

Но также подумайте о том, что происходит с каждым URL:

GET http://example.com/aritcles/ может вернуть все текущие статьи

GET http://example.com/aritcles/authors/ Что делает этот URL? возвращает ли он всех авторов всех статей или возвращает все статьи для всех авторов (что по сути является той же функциональностью, что и URL-адрес выше)

GET http://example.com/aritcles/authors/5/ может возвращать все статьи автора 5 или информация об авторе 5?

Я мог бы изменить его на:

http://example.com/aritcles возвращает все статьи
http://example.com/aritcles/5 возвращает все статьи автора 5
http://example.com/authors возвращает всех авторов
http://example.com/authors/5 возвращает информацию об авторе 5

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...