Атрибуты: ограничены ли текущие инструменты REST-архитектуры древовидной структурой?

Question

Исторически структуры каталогов операционной системы были деревьями:

• C:
  • Windows
    • 1008 * System32 *
  • Программные файлы
    • Общие файлы
    • Internet Explorer

И архитектура REST эмулирует то же самое:

• Http: //...//Thomas/
• Http: //...//Thomas/Mexico/Year2003/Photos
• Http: //...//Thomas/Mexico/Year2007/Photos
• Http: //...//Thomas/Finland/Year2005/Photos
• Http: //...//Thomas/Finland/Year2010/Photos
• Http: //...//Thomas/Finland/Year2010/Videos
• Http: //...//Thomas/USA/Year2005/Photos

Но, просматривая текущую структуру, мне нужно сделать поиск:

• Все фотографии, которые не из Финляндия?
• Все снимки сделаны в 2005 году?
• Все картинки на временной шкале?

Неэффективно создавать REST-интерфейс с каждой комбинацией иерархии деревьев. Вам нужно более эффективное управление информацией; вам нужна система атрибутов, а не древовидная структура. (О, почему операционные системы не основаны на атрибутах?)

StackOverflow и Google, похоже, используют атрибуты и синтаксис со знаком "+", такими как:

• http://www.stackoverflow.com/Tags/asp.net+iis7
• http://www.google.com/search?&q=iis7+asp.net

Современные фреймворки, такие как WCF и ASP.NET MVC, хорошо поддерживают древовидные структуры RESTful. Но есть ли поддержка атрибутных структур? Не могли бы вы назвать структуру атрибутов все еще REST?

Я хотел бы создать атрибут-WebService и использовать его с LINQ в Silverlight-клиенте ... Какой лучший способ начать? : -)

Answer 1

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

Все картинки, которые не из Финляндии? Все фотографии сделаны в 2005 году? Все фотографии в сроки?

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

/Thomas/pictures

Здесь вы хотите иметь возможность ограничить содержимое этого ресурса с помощью параметров запроса.

/Thomas/pictures?country=not-finland
/Thomas/pictures?year=2005

В случае третьего элемента может иметь смысл создать отдельный ресурс для этого элемента.

/Thomas/PictureTimeline

Существуют другие сценарии, в которых может иметь смысл создать дополнительный ресурс, например

/Thomas/FavouritePictures

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

Answer 2

Туомас,

вам нужны параметры матрицы URI: http://www.w3.org/DesignIssues/MatrixURIs.html Когда использовать параметры запроса в сравнении с параметрами матрицы? .

Jan