стандартный способ кодирования информации о нумерации страниц по релакс-URL получить? - PullRequest
Новая
       11

стандартный способ кодирования информации о нумерации страниц по релакс-URL получить?

4 голосов
/ 30 мая 2009

Я думаю, что мой вопрос лучше объяснить парой примеров ...

GET http://myservice/myresource/?name=xxx&country=xxxx&_page=3&_page_len=10&_order=name asc

то есть, с одной стороны, у меня есть условия (name = xxx & country = xxxx), а с другой стороны, у меня есть параметры, влияющие на запрос (_page = 3 & _page_len = 10 & _order = name asc)

Теперь я хотел бы использовать какой-то специальный префикс (в данном случае "_"), чтобы избежать коллизий между условиями и параметрами (что если у моего ресурса есть свойство "order"?)

Есть ли какой-нибудь стандартный способ справиться с этими ситуациями?

-

Я нашел этот пример (просто чтобы выбрать один) http://www.peej.co.uk/articles/restfully-delicious.html

GET http://del.icio.us/api/peej/bookmarks/?tag=mytag&dt=2009-05-30&start=1&end=2

но в этом случае поля условий уже определены (нет ни начального, ни конечного свойства)

Я ищу какое-то общее решение ...

- изменить, более подробный пример, чтобы уточнить

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

так что URL может быть что-то вроде

http://myservice/customers/?country=argentina,last_operation=2009-01-01..2010-01-01

Это должно дать мне всех клиентов из Аргентины, которые купили что-нибудь в прошлом году

Теперь я хотел бы использовать этот сервис для создания страницы просмотра или для заполнения комбо, например, с помощью ajax, поэтому идея заключалась в том, чтобы добавить метаду, чтобы контролировать, какую информацию я должен получить

для создания страницы просмотра я бы добавил

Http: //...,_page=1,_page_len=10,_order=state,name

и заполнить автозаполнение комбо ajax

Http: //...,_page=1,_page_len=100,_order=state,name,name=what_ever_type_the_user*

, чтобы заполнить комбо с первыми 100 клиентами, соответствующими тому, что набрал пользователь ...

У меня был вопрос, был ли какой-то стандартный (написанный или нет) способ кодирования такого рода вещей в перефразированной форме URL ...

Ответы [ 4 ]

2 голосов
/ 12 ноября 2013

Хотя стандарта не существует, Дизайн веб-API (от Apigee) - отличная книга советов при создании веб-API. Я отношусь к нему как к некоему стандарту и всегда следую его рекомендациям.

В разделе «Нумерация страниц и частичный ответ» они предлагают (стр. 17):

Использовать лимит и смещение

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

/dogs?limit=25&offset=50
2 голосов
/ 31 мая 2009

Примечание: Я начал писать это как комментарий к моему предыдущему ответу . Затем я собирался добавить это как редактирование, но я думаю, что вместо этого он принадлежит как отдельный ответ. Это совершенно другой подход и отдельный ответ сам по себе, поскольку это другой подход.

Чем больше я об этом думаю, тем больше у меня есть два разных ресурса, с которыми вам приходится иметь дело:

  1. Страница ресурсов
  2. Каждый ресурс, который собирается на странице

Возможно, я что-то упустил (может быть ... я был виновен в неправильном толковании). Поскольку страница сама по себе является ресурсом, пейджинговая метаинформация действительно является атрибутом ресурса, поэтому размещение ее в URL-адресе не обязательно является неправильным подходом. Если вы рассмотрите, что может быть кэшировано в нисходящем направлении для страницы и / или упоминаться как ресурс в будущем, этот ресурс определяется атрибутами пейджинга и параметрами запроса, поэтому они оба должны быть в URL. Если продолжить с моим слишком длинным ответом, ресурс страницы будет выглядеть примерно так: 

http://.../myresource/page-10/3?name=xxx&country=yyy&order=name&orderby=asc

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

Другой ресурс называет каждый элемент, содержащийся на странице. То, как идентифицируются предметы, должно контролироваться ресурсами. Я думаю, что ключевой вопрос состоит в том, стоят ли ресурсы результата самостоятельно или нет. То, как вы представляете ресурсы item , зависит от этой концепции.

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

http://.../myresource/page-10/3?...#5
http://.../myresource/page-10/3/5?...

Наибольшим фактором при выборе между этими двумя является то, насколько сильно отдельный элемент связан со страницей. Синтаксис фрагмента значительно более обязателен, чем элемент пути IMHO.

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

http://.../myresource/item/42
http://.../myresource/item/307E8599-AD9B-4B32-8612-F8EAF754DFDB

Ключевым решающим фактором является то, являются ли предметы автономными ресурсами или нет. Если это не так, то они являются производными от URI страницы. Если они являются автономными, то они должны иметь свои собственные ресурсы и должны быть включены в ресурс page как ссылки.

2 голосов
/ 30 мая 2009

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

1 голос
/ 30 мая 2009

Я знаю, что RESTful люди, как правило, не любят использование заголовков HTTP, но кто-то действительно изучал использование диапазонов HTTP для решения нумерации страниц. Несколько лет назад я написал расширение ISAPI, которое включало информацию о нумерации страниц вместе с другой информацией, не относящейся к собственности, в URI, и мне никогда не нравилось ощущение этого. Я думал о том, чтобы сделать что-то вроде: 

GET http://...?name=xxx&country=xxxx&_orderby=name&_order=asc HTTP/1.1
Range: pageditems=20-29
...

Это помещает параметры набора результатов (например, _orderby и _order) в URI и выбирает в качестве заголовка Range. У меня такое ощущение, что большинство реализаций HTTP могут это испортить, тем более что поддержка небайтных диапазонов МОЖЕТ в RFC2616. Я начал более серьезно думать об этом после того, как проделал кучу работы с RTSP . Заголовок Range в RTSP является хорошим примером расширения диапазонов для обработки времени, а также байтов.

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

myresource/name=xxx;country=xxx/orderby=name;order=asc/20/
myresource/name=xxx;country=xxx/orderby=name;order=asc/21/
myresource/name=xxx;country=xxx/orderby=name;order=asc/22/
myresource/name=xxx;country=xxx/orderby=name;order=asc/23/
myresource/name=xxx;country=xxx/orderby=name;order=asc/24/

Я не уверен, пробовал ли кто-нибудь что-то подобное или нет. Это сделало бы URI конструктивными, что всегда является полезным свойством ИМХО. Преимущество этого подхода заключается в том, что отдельные ответы могут быть кэшированы, и сервер может оптимизировать обработку страниц сбора элементов и что-то не так эффективно. Основная идея состоит в том, чтобы клиент указывал запрос в URI и индекс элемента, который он хочет получить. Нет необходимости вставлять идею "страницы" в ресурс или даже сделать его видимым. Клиент может итеративно извлекать объекты до тех пор, пока страница не заполнится или не получит 404.

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

...