Рекомендации по иерархии имен URI - PullRequest
Новая
       21

Рекомендации по иерархии имен URI

0 голосов
/ 25 ноября 2010

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

В результате выбора подходящей иерархии URI я в настоящее время хожу по кругу. Например, я мог бы реализовать ...

1) i) версия / спорт / лига / сезон / сущность

1) ii) версия / сущность / спорт / лига / сезон

1) iii) версия / спорт / сущность / лига / сезон

Пример проясняет ситуацию (надеюсь) ...

Возьмите запрос, чтобы вернуть всех футболистов, которые играют в премьер-лиге в сезоне 2010/2011 ...

2) i) 1.1 / футбол / premier_league / 2010_2011 / игроков

2) ii) a) 1.1 / игроков / футбол // premier_league / 2010_2011

Но не во всех видах спорта (например, скачки - лошадь и жокей, F1 и т. Д.) Действительно есть игроки, поэтому игроки должны прийти после спорта?

2) ii) б) 1,1 / лошадей / horse_racing / gold_cup / 2010

2) iii) а) 1.1 / футбол / игроков / premier_league / 2010_2011

2) iii) б) 1,1 / скачки / 1039 * лошадей / gold_cup / 2010

Дополнительные примеры URI ниже ...

1,1 / игроки / футбол / premier_league / 2010_2011 / команды / {ID}
возвращает игроков в команду на сезон?

1,1 / Игроки / футбол / premier_league возвращает игроков в премьер-лигу?

1,1 / Результаты / футбол / premier_league / 2010_2011 / команды / {ID} возвращает результаты командного сезона?

также я предполагаю такие запросы как ...

1,1 / футбол / premier_league / 2010_2011 / Ноябрь / команды / {ID} / * Результаты 1062 *

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

Если бы служба включала в себя не спортивные объекты, скажем, политические выборы ... не было бы игроков ...

1,1 / Выборы / 2012 / партии / {ID} / Результаты
возвращает результаты для политической партии

1,1 / Выборы / 2012 / партии / {ID} / кандидаты возвращает кандидатов, связанных с партией

или 1,1 / Результаты / Выборы / 2012 / партии / {ID} возвращает результаты для политической партии

1,1 / кандидаты / Выборы / 2012 / партии / {ID} возвращает кандидатов, связанных с партией

Какой совет по какой иерархии лучше? Я пытался найти этот сайт и Google, но примеры, которые я нашел, охватывали только тривиальные случаи. Я думаю, что я поддерживаю пример 2-III.

Заранее спасибо.

1 Ответ

3 голосов
/ 26 ноября 2010

Мой совет - создать идентификаторы для ваших сущностей, которые содержат минимальный объем необходимой информации.например, 

/sport/{unqiueId}
/player/{unqiueId}
/horse/{unqiueId}
/team/{unqiueId}
/league/{unqiueId}
/season/{unqiueId}
/result/{unqiueId}

Обратите внимание, что я удалил версию из URL, поскольку твердо нахожусь в лагере, который считает, что версии не входят в URL.

Отношения «один-к-одному» можно обрабатывать путем встраивания ссылок на сущности в ответ: например, 

GET /player/234
=>
<Player Name="Kenny Dalglish">
   <Link rel="team" href="/team/732"/>
</Player>

Отношения «один-ко-многим» можно обрабатывать аналогичным образом, но для этого требуется создать подчиненную-ресурс ресурса сущности. 

GET /team/732
=>
<team Name="Liverpool FC">
   <Link rel="players" href="/team/732/players"/>
</Player>

Обычно вы найдете все виды сценариев, в которых этот шаблон полезен: 

/league/{unqiueId}/teams
/league/{unqiueId}/players
/season/{unqiueId}/teams
/league/{unqiueId}/seasons
/player/{unqiueId}/teams
/sport/{unqiueId}/teams
/sport/{unqiueId}/leagues
/sport/{unqiueId}/seasons

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

GET /league/891
=>
<league Name="Premiership">
   <link rel="leaderboard" href="/league/891/teams?startposition=1&endposition=10"/>
   <link rel="currentseason" href="/season/972"/>
   <link rel="lastseason" href="/season/842"/>
   <link rel="sport" href="/sport/1"/>
   <link rel="teams" href="/teams?league=891/>
</league>

Одна из интересных характеристик этого типа "API" является то, что вместо того, чтобы встроить всю нагрузку правил в ваше клиентское приложение наКак построить структуру URL, чтобы сделать запрос, клиентское приложение использует другой подход.Клиент должен знать начальный URL и значение значений атрибута rel.Оттуда клиент может просто перемещаться, чтобы получить то, что он хочет.например,

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

GET /Sport/Football/League/Premiership/Season/2011/Teams

вместо этого он перемещается по своему пути к результату, как этот: 

GET /
=>
<SportData>
  <Link rel="sport football" href="/sport/1"/>  <!-- Client finds this link -->
  <Link rel="sport horseracing" href="/sport/2"/>
  ...
</SportData>

GET /sport/1
=>
<Sport Name="Football">
  <Link rel="league premiership" href="/league/891"/>  <!-- Client finds this link -->
  ...
</Sport>

GET /league/891
=>
<League Name="Premiership">
  <Link rel="season 2011" href="/season/2334"/>  <!-- Client finds this link -->
  ...
</League>


GET /season/2334
=>
<Season Name="2011">
  <Link rel="teams" href="/season/2334/teams"/>  <!-- Client finds this link -->
  ...
</Season>

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

В идеале в системе на основе REST единственной связью между клиентом и сервером является корневой URL-адрес и типы мультимедиа, которые отправляются туда и обратно.Клиенту ничего не нужно знать о пространстве URL сервера.

...