Получение количества возвратов, видимых с помощью запроса RESTful

Итак, я хотел бы узнать, сколько результатов я получу назад из запроса RETful uri GET. На данный момент я не знаю, как это сделать. Есть ли способ сделать это? Поскольку REST просто выбрасывает свойства, я не знаю, способен ли он подсчитать его результаты, но он может пропустить результаты и взять подмножество результатов.

У кого-нибудь есть предложения?

О, моя настройка - это LINQ to SQL, которая заполняет список с общим набором. Служба данных делает этот список доступным. Я попытался получить счет в списке, но я всегда возвращаю максимальные строки базы данных, и это не то, что я ищу.

Ответ 1

Другие люди могут возражать против этой концепции, но это кажется мне разумным:

HEAD /your/api HTTP/1.1

HTTP/1.1 200 OK
Date: Fri, 23 Oct 2009 00:58:17 GMT
Content-Type: application/xml; charset=UTF-8
Content-Length: 89
X-Result-Count: 100000000

И затем:

GET /your/api HTTP/1.1

HTTP/1.1 200 OK
Date: Fri, 23 Oct 2009 00:58:17 GMT
Content-Type: application/xml; charset=UTF-8
Content-Length: 89
X-Result-Count: 100000000

<?xml version="1.0" encoding="UTF-8"?>
<results>
  100000000 results go here.
</results>

Примечание: Здесь используется HEAD-запрос, чтобы получить счетчик без необходимости вытягивать полный набор данных. Запросы HEAD извлекают только HTTP-заголовки, а не тело ответа.

Это был бы самый RESTful способ, я могу думать о том, сколько результатов вы получите, прежде чем отправлять его по проводу. Главный трюк просто подходит для лучшего заголовка для него. X-Result-Count является приличным, но если вы можете найти предыдущий уровень и повторно использовать свой выбор заголовка, это будет еще лучше (если они не назовут его чем-то действительно глупым). Тем не менее, я не ожидаю, что у вас будет много удачи, поэтому вам следует придерживаться X-Result-Count.

Кроме того, я думаю, вы, возможно, неправильно поняли, что на самом деле подразумевает "REST". Нет причин, по которым вы не можете представить представление по диапазону. Например:

GET /your/api?page=1&perpage=10 HTTP/1.1

HTTP/1.1 200 OK
Date: Fri, 23 Oct 2009 00:58:17 GMT
Content-Type: application/xml; charset=UTF-8
Content-Length: 101
X-Result-Count: 10

<?xml version="1.0" encoding="UTF-8"?>
<results>
  First 10 results of 100000000 go here.
</results>

Однако, чтобы быть RESTful, вы должны иметь возможность сообщить клиенту о представлении, идентифицированном /your/api?range=0-9 или /your/api?page=1&perpage=10, без использования информации вне диапазона. Например, если ваша страница /your/api вернет слишком много результатов, выполните временную переадресацию на /your/api?page=1&perpage=10 и включите гиперссылки на /your/api?page=2&perpage=10. Обратите внимание, что гиперссылка в этом контексте может быть чем-то простым:

<?xml version="1.0" encoding="UTF-8"?>
<results>
  <result>
    This is a result.
  </result>
  <result>
    This is also a result.
  </result>
  <link rel="next" href="/your/api?page=3&perpage=2" />
  <link rel="prev" href="/your/api?page=1&perpage=2" />
</results>

Теперь информация для навигации по результатам ваших вызовов API является внутриполосной и фактически RESTful.

По сути, REST - это простой-HTTP-код с кешированием, сделанным правильно, и обычно чувствительные URI, которые были выбраны для хорошей меры. Это также "гипертекст как механизм состояния приложения" (то есть ресурсы должны ссылаться на другие ресурсы). Это не протокол, это архитектурный стиль. Любой, кто говорит вам по-другому, лучше называться Роем Филдингом.

Addenda:

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

X-Result-Count: 0-9/100000000

Или отрегулируйте по мере необходимости.

Ответ 2

Почему бы веб-службы REST не вернуть данные как JSON или XML, и там вы можете иметь свойство о длине.

Ответ 3

Вы можете позаботиться об этом в своем дизайне имени ресурса REST. Вы начнете с чего-то вроде:

/widget/12345 (представление виджета 12345)
/widgets (список всех имен ресурсов виджетов, т.е. ссылок)

Вы можете быстро решить, что "/widgets" будет обширным списком и решит поддерживать страницы, что-то вроде

/widgets/page/43 (это может иметь ссылки на 4200-е-4299-е виджеты и дополнительную информацию, такую как общее количество страниц или количество виджетов.)

В других случаях вы можете разделить большой набор на естественную иерархию:

/widgets/mahogany,/widgets/oak,...
/фильмы/драма, фильмы/романтика,...
/компьютеры/жесткие диски /seagate,/computers/usbdrives/kingston

И вы также можете задать запросы:

/виджетов maxprice = 200 &? Maxweight = 4

Ответ 4

Почему бы вам не обрабатывать запросы обработчика ресурсов для этого типа метаданных? Предположим, что

GET /items

возвращает список таких элементов:

<items count="5" modified="2009-10-22">
  <item url="/items/first" name="First Item" />
  <item url="/items/second" name="Second Item" />
  ...
</items>

Затем что-то вроде:

GET /items?info

может возвращать пустой список:

<items count="5" modified="2009-10-22" type="info" />

или, возможно, общий информационный документ:

<info>
  <items count="5" modified="2009-10-22" url="/items" />
</info>

Вы также можете реализовать ресурс "info", например:

GET /info?items&users

который может вернуться:

<info>
  <items count="5" modified="2009-10-22" url="/items" />
  <users count="8" modified="2009-10-05" url="/users" />
</info>