Altre persone potrebbero avere obiezioni a questo concetto, ma, questo mi sembra ragionevole:
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
E poi:
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>
Nota: una richiesta HEAD è qui utilizzato per ottenere il conteggio senza dover estrarre l'intero set di dati. Le richieste HEAD recuperano solo le intestazioni HTTP, non il corpo della risposta.
Questo sarebbe il modo più RESTful in cui posso pensare di indicare quanti risultati tornerai prima di inviarlo via cavo. Il trucco principale sta proprio nel trovare il miglior nome di intestazione per questo. X-Result-Count è decente, ma se riesci a trovare la tecnica antecedente e riutilizzare la scelta del nome dell'intestazione, sarebbe ancora meglio (a patto che non la chiamassero qualcosa di veramente stupido). Detto questo, non mi aspetto che avrai molta fortuna, quindi dovresti probabilmente attaccare con X-Result-Count.
Inoltre, penso che potresti aver frainteso ciò che "REST" in realtà comporta. Non c'è motivo per cui non puoi dare una rappresentazione per intervallo. Per esempio:
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>
Tuttavia, per essere riposante, è necessario essere in grado di dire al cliente circa la rappresentazione identificato da /your/api?range=0-9 o /your/api?page=1&perpage=10 senza l'utilizzo di informazioni out-of-band. Ad esempio, se la tua pagina /your/api restituisce troppi risultati, esegui un reindirizzamento temporaneo su /your/api?page=1&perpage=10 e includi collegamenti ipertestuali a /your/api?page=2&perpage=10. Si noti che un collegamento ipertestuale in questo contesto potrebbe essere qualcosa di semplice come:
<?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>
Ora le informazioni per navigare i risultati delle vostre chiamate API è in banda ed effettivamente RESTful.
In sostanza, REST è semplicemente HTTP vecchio con il caching fatto correttamente e gli URI di solito sensibili inseriti per buona misura. È anche "l'ipertesto come motore dello stato dell'applicazione" (vale a dire che le risorse devono essere collegate ad altre risorse). Non è un protocollo, è uno stile architettonico. Chiunque ti dica diversamente è meglio che si chiami Roy Fielding.
Addenda:
Se si desidera indicare il conteggio totale contro il numero di pagine, è possibile definire l'intestazione in questo modo:
X-Result-Count: 0-9/100000000
Oppure regolare se necessario.
Non so cosa si intende per la sua affermazione che "REST lancia solo proprietà." –
Scusa, volevo dire che mostra solo i dati. Non è come SOAP dove puoi ottenere un risultato chiamando una funzione. Certo, puoi manipolare quei dati e modificarli in qualche modo prima di esporli, ma questo è fondamentalmente ciò che intendevo. – georryan