Обратитесь к упорядоченному списку RESTful способом - PullRequest
Новая
       7

Обратитесь к упорядоченному списку RESTful способом

3 голосов
/ 23 марта 2012

Я сомневаюсь, как лучше обращаться с упорядоченным списком в RESTful API.Представьте себе следующий пример: Давайте создадим список графиков LP, куда вы хотите добавить новые LP, удалите те, которых еще нет в TOP10, и измените их позиции.Как бы вы реализовали эти методы в RESTful JSON-API?

Я подумал о следующем пути:

  • GET / , чтобы вернуть упорядоченный список диаграмм, как[{ "name": "1st-place LP", "link": "/uid123" }, { "name": "2nd-place LP", "link": "/uid987" }, ...]
  • GET / {uid} для возврата LP по уникальному идентификатору, возвращая sth.например {"name": "1st-place LP", "ranking": 1 }
  • GET / rank / {position} для доступа, например, к текущему первому рейтингу LP, возвращающему 303 See Other с заголовком Location, например Location: /uid123
  • POST / с телом запроса { "name": "my first LP title" } для создания нового LP без указания его текущей позиции на графике

Теперь вопрос в том, как мы можем изменить текущие позиции на графике?Можно просто PUT / {uid} обновить атрибут ranking, но я думаю, что PUT / Ranking / {position} будет более естественным.С другой стороны, не имеет смысла ставить PUT против URI, который будет возвращать 303 See Other при использовании GET.

Как вы думаете, что было бы лучшим способом для обращения к такому списку диаграмм?Мне не нравится решение просто изменить атрибут ranking в наборах данных LP, поскольку это может закончиться бессмысленными состояниями, такими как два LP с одинаковым ранжированием и т. Д.

Ответы [ 2 ]

1 голос
/ 24 марта 2012

Я вижу два вопроса.1. Какой самый RESTful (красивый) способ разработки API?2. Как я могу убедиться, что два LP не получают одинаковый рейтинг?

1: Ваши LP могут иметь несколько свойств, относящихся друг к другу, например, различное ранжирование на разных графиках.Я бы сказал, что вы хотите, чтобы рейтинг переместился за пределы вашего LP-ресурса.Держите рейтинг в определенном списке как отдельный ресурс.Пример:

  • GET / LPuid возвращает только свойства, относящиеся к LP, а не относительные свойства, такие как ранжирование.
  • GET / billboard / 3 возвращает URI для LP с ранжированием 3 на билборде.list.
  • PUT / billboard принимает документ из 100 LP URI.
  • PUT / billboard / 3 Устанавливает LP URI в этот рейтинг и перемещает остальные.

2: Это не имеет никакого отношения к отдыху, и у вас возникнет эта проблема, независимо от того, как вы разрабатываете свой API.Транзакции - это одно из решений.

0 голосов
/ 05 декабря 2012

У вас есть два ресурса коллекции в вашем музыкальном сервисе.Таким образом, я бы разработал структуру URI следующим образом: 

/ => returns links to collections (ergo itself a collection resource)
/releases => returns a list of LPs
/chart => returns the top 10 LPs, or redirects to the current chart URI

Вы бы POST до /releases добавили бы новый LP, и PUT или PATCH до /chart, чтобы определитьновый график или изменить текущий график.Вам нужно будет определить, какие форматы представления передаются в каждом конкретном случае.

Это дает вам гибкость для определения мыслей, подобных /chart/2012-12-25, для отображения диаграммы в том виде, в каком она была на Рождество 2012 года.Я не предлагаю использовать PUT /chart/{position}, чтобы вставить LP в определенную позицию и перемешать все остальное вниз.Intermediarys не будет знать, что PUT для этого URI заставляет другие ресурсы изменять свои URI.Это плохо для кеширования.

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

...