шаблон проектирования для зависимого ресурса в REST - PullRequest
Новая
       8

шаблон проектирования для зависимого ресурса в REST

3 голосов
/ 22 ноября 2011

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

http://example.com/books.json?author=Homer

{"books": [
    {"id": 33, "title": "Iliad", "author": "Homer", "pubyear": "800 BC"},
    {"id": 33, "title": "Odyssey", "author": "Homer", "pubyear": "750 BC"}
]}

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

Для подсчета мой инстинкт должен сделать следующее 

http://example.com/books/count.json?author=Homer

{"books": [
    {"count": 2}
]}

или даже 

http://example.com/books/stats.json?author=Homer

{"books": [
    {"stats": {
        "count": 2,
        "units": 10,
        "sold": 3
    }
]}

Но, похоже, правильный путь действительно должен быть 

http://example.com/books.json/count?author=Homer or
http://example.com/books.json?aggregate=count&author=Homer

есть предложения, мысли?

1 Ответ

0 голосов
/ 22 ноября 2011

Причина, по которой обе стороны кажутся странными, заключается в том, что вы смешиваете тип контента и идентификатор контента, помещая в него «.json». Тип содержимого должен быть в заголовке запроса «Принять». Если вы удалите «.json», две рассматриваемые вами возможности сведутся к одному и тому же.

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

...