Inni ludzie mogą mieć zastrzeżenia do tej koncepcji, ale to wydaje się rozsądne, aby mnie:
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
, a następnie:
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>
Uwaga: Żądanie HEAD jest tutaj stosowane do uzyskania licznik bez konieczności ciągnięcia pełnego zestawu danych. Żądania HEAD pobierają tylko nagłówki HTTP, a nie treść odpowiedzi.
To byłoby najbardziej relaksującego sposób mogę myśleć co wskazuje ile wyniki dostaniesz z powrotem przed wysłaniem go na drucie. Główna sztuczka polega właśnie na wymyśleniu najlepszej nazwy nagłówka. X-Result-Count jest przyzwoity, ale jeśli uda Ci się znaleźć wcześniejsze wersje i ponownie użyć ich nazwy nagłówka, to będzie jeszcze lepiej (o ile nie nazwali tego czymś naprawdę niemym). Powiedział, że nie oczekuję, że będziesz miał dużo szczęścia, więc powinieneś prawdopodobnie trzymać się z X-Result-Count.
Sądzę też, że źle zrozumiałeś, co właściwie oznacza "REST". Nie ma powodu, dla którego nie można podać reprezentacji według zasięgu. Na przykład:
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>
Jednakże, aby być relaksującego, trzeba być w stanie powiedzieć klienta o przedstawienie zidentyfikowanego przez /your/api?range=0-9 lub /your/api?page=1&perpage=10 bez użycia out-of-band informacji. Na przykład, jeśli twoja strona /your/api zwróci zbyt wiele wyników, zrób tymczasowe przekierowanie do /your/api?page=1&perpage=10 i dołącz hiperłącza do /your/api?page=2&perpage=10. Zauważ, że hiperłącze w tym kontekście może być coś prostego jak:
<?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>
Teraz informacja nawigować wyniki swoich API jest w paśmie i rzeczywiście spokojny.
Zasadniczo REST jest zwykły stary HTTP z buforowania zrobione dobrze i zazwyczaj rozsądne URI rzucony w środek na dobre. Jest to również "hipertekst jako motor stanu aplikacji" (tzn. Zasoby powinny łączyć się z innymi zasobami). To nie jest protokół, to styl architektoniczny. Każdy, kto mówi ci inaczej, powinien być lepiej nazwany Roy Fielding.
Addenda:
Jeśli chcesz podać całkowitą liczbę w stosunku do liczby stron, można zdefiniować nagłówek tak:
X-Result-Count: 0-9/100000000
Lub wyreguluj w razie potrzeby.
Nie wiem co masz na myśli przez twierdzenie że "REST po prostu wyrzuca właściwości". –
Przepraszam, chodzi mi o to, że po prostu ujawnia dane. To nie jest tak, jak SOAP, gdzie można uzyskać wynik, wywołując funkcję. To prawda, możesz manipulować danymi i zmienić je w pewnym stopniu, zanim je wyeksponujesz, ale w zasadzie to właśnie miałem na myśli. – georryan