Is there really no other truly RESTful way to get the data you need in 1 or 2 requests?
- Non proprio
- Ma non pensarci troppo
Come al solito, quando pensi a REST, tieni presente che esiste un'implementazione di riferimento (il World Wide Web) che puoi controllare.
Considera il portale Amazon - quando apro quel segnalibro con una cache vuota, vedo che il mio browser fa richieste a 275 risorse.
Otterrei una latenza migliore se tutto questo stato venisse recuperato in un singolo carico utile? Sì.
Sarebbe in scala? sarebbe su scala web? Probabilmente no. Questo è 4,5 MB di dati che non possono essere condivisi perché include 1 KB specifico per il mio profilo. Se il mio collega alla scrivania accanto a me va anche su Amazon, lei tira gli stessi dati attraverso la rete.
Decompone il carico utile in risorse indirizzabili individualmente, e improvvisamente le cose migliorano molto - ognuno di noi ha ancora il nostro 1KB di personalizzazione, e ognuno di noi ha ancora la nostra copia cache locale del 4,5 MB, ma non abbiamo avuto bisogno di colpire la rete con tanta forza, perché la maggior parte delle nostre richieste era servita da una cache condivisa locale, piuttosto che dover essere instradata su Internet.
Inoltre, tieni presente che non hai davvero un problema con più risorse , hai un problema con più richieste . Questo può essere mitigato usando Prompt di push HTTP / 2.0 , con il server che spinge proattivamente le rappresentazioni che possono essere memorizzate nella cache. Forse - un server senza stato non sa cosa ha memorizzato il client nella cache, e TLS suggerisce che la memorizzazione nella cache degli intermediari non è una priorità ....
This means that if you needed to, say, query for a list of the 100 most recently logged in users, and display their names and emails, you'd need to first do a GET query for the list of results, which would (essentially) be a list of link elements, with each link object containing the URI of a user resource. You would then need to make 100 more GET requests -- one for each user resource -- before you'd actually have the data you need to display your results.
Naturalmente, se lo facessi in html, la tua rappresentazione degli utenti che hanno effettuato l'accesso più recente probabilmente sarebbe un documento con un elenco o una tabella di nomi e indirizzi e-mail e collegamenti a tali risorse. Ta-da.
Non perdere traccia di questa osservazione con Fielding.
That doesn’t mean that I think everyone should design their own systems according to the REST architectural style. REST is intended for long-lived network-based applications that span multiple organizations. If you don’t see a need for the constraints, then don’t use them.
Modifica
can i make the same argument for a JSON representation? ie, if the resource in question is "100 last logged in users" rather than results of a parameterized query, can i then return the data itself instead of resource links? if not, why? why is JSON essentially different from HTML in this regard?
Come sono simili: l'inserimento di più dati nella "lista dei risultati" consente di risparmiare i costi delle richieste aggiuntive, compromettendo allo stesso tempo il ridimensionamento. Il tipo di media specifico che stai usando per la rappresentazione non ha importanza - almeno, per quanto ne so.
Come sono diversi: HTML è un formato ipermediale e JSON no - qualsiasi implementazione client standard di bog che abbia familiarità con le specifiche HTML saprà come trovare i collegamenti in un documento HTML, che supporta opzioni come -fetching. JSON non ha questa standardizzazione: sono necessarie informazioni fuori banda sulla struttura dei dati per capire dove si trovano i collegamenti in una rappresentazione JSON. HAL sarebbe una corrispondenza più stretta con HTML in questo senso; la differenza principale tra HAL e HTML è l'adozione; HTML ha 20 anni di vantaggio?
Per ulteriori approfondimenti, potresti anche prendere in considerazione la revisione del Atom Syndication Format , che descrive sia le voci che i feed (elenchi di Voci), in particolare le regole per atom: entry , a cui è possibile accedere tramite una risorsa autonoma o tramite una risorsa feed.