Использование архитектуры RESTful для доступа к многомерным данным - PullRequest
Новая
       19

Использование архитектуры RESTful для доступа к многомерным данным

3 голосов
/ 19 августа 2010

Как мы должны использовать REST для эффективного доступа к многомерным данным?Варианты выбора: hi-REST, lo-REST или OpenSearch (что похоже на специализацию lo-REST).

Ответы [ 2 ]

2 голосов
/ 19 августа 2010

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

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

OpenSearch является абсолютно RESTful-решением этой проблемы, и в этом он дружествен к программисту. Большая часть использования OpenSearch ограничена простыми читаемыми результатами поиска HTML, но в действительности его можно использовать и для чисто машиночитаемых (например, атомных) результатов поиска: 

<Url type="application/atom+xml"
     template="...search/?q={searchTerms}"/>

Этот шаблон инструктирует клиентов, что если вы хотите представление атома, вы можете перейти сюда. Но как это соответствует многомерным данным? Расширяемость OpenSearch вступает в игру здесь. Расширение времени OpenSearch описывает, как инструктировать клиентов создавать URL-адреса, представляющие запросы, ограниченные определенным временным диапазоном (при условии, что xmlns:time привязан правильно: 

<Url type="application/atom+xml"
     template="...search/?after={time:start}&amp;before={time:end}"/>

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

Чтобы расширить OpenSearch, я должен обозначить пространство имен и некоторые элементы в этом пространстве имен, чтобы обозначить что-то конкретное. Это должно быть где-то опубликовано, чтобы другие могли получить доступ к документации и внедрить свои собственные серверы и клиентов. Допустим, вы хотите найти клиента по фамилии; Фамилия - довольно общий термин, но недостаточно универсальный, чтобы его стандартизировать. Допустим, я определяю пространство имен, связываю его с префиксом name в моем описании OpenSearch и открываю следующий шаблон: 

<Url type="application/atom+xml"
     template="...search?lastName={name:last}"/>

Этот шаблон инструктирует любого клиента, который понимает мое пространство имен name, что он может выполнять поиск по фамилии, заполнив шаблон.

Это все еще не многомерно, но давайте добавим еще одно измерение; географии. К счастью, есть черновое расширение OpenSearch для географии , которое позволяет выполнять поиск в пределах ограничительной рамки или круга: 

<Url type="application/atom+xml"
     template="...search/?latitude={geo:lat?}&amp;
                          longitude={geo:lon?}&amp;
                          metres={geo:radius?}"/>

Я делю шаблон, чтобы сделать его читаемым.

Шаблон по-прежнему не многомерен, поскольку он позволяет выполнять поиск только в одном измерении (геопространственном). Итак, как вы делаете многомерный поиск? Вы предоставляете шаблон, который показывает, как выполнять многомерный поиск, который имеет смысл объединить:

например. Вот шаблон, который позволяет мне найти людей с заданной фамилией в другом регионе (два измерения): 

<Url type="application/atom+xml"
     template="combo-find?customerLastName={name:last}&amp;
                          lat={geo:lat?}&amp;
                          lon={geo:lon?}&amp;
                          radius={geo:radius?}"/>

Вот шаблон, который позволяет мне ограничивать имена и геопространственные данные, а также временные ограничения (хотя расширение OpenSearch Time ничего не говорит о том, какое время вы ищете): 

<Url type="application/atom+xml"
     template="...search/?lastName={name:last}&amp;
                          lat={geo:lat?}&amp;
                          lon={geo:lon?}&amp;
                          r={geo:radius?}&amp;
                          after={time:start}&amp;
                          before={time:end}"/>

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

RESTfulness всего этого потому, что все ограничения REST соблюдаются; он не имеет состояния, гипермедиа - это движок, он многоуровневый и т. д. OpenSearch - это просто еще один гипермедиа формат, очень хороший в этом!

0 голосов
/ 19 августа 2010

Судя по моему поиску в Google терминов hi-REST и lo_REST, я не думаю, что какой-либо выбор будет иметь большое значение для эффективности.Скорее, это скорее вопрос насколько «правильным» вы хотите быть.

Hi-REST, возможно, более «правильный», но я сомневаюсь, что использование Hi-RESTокажет какое-либо существенное влияние на эффективность.Представление данных, которое вы выбираете для транспортировки данных (например, XML, Binary XML, JSON и т. Д.), Будет иметь гораздо большее влияние на производительность данных.

...