Tutto questo può capitare di essere molto newbish, ma sto cercando di capire come progettare un sito web che sia completamente RESTful. Comprendo l'applicazione del design RESTful a cose come utenti, foto, post di blog, ecc. Perché li considero come "oggetti".
Ma che dire di una pagina "chi siamo"? Che tipo di risorsa è? È anche una risorsa nel senso RESTful della parola? Inoltre, dire che vado all'URL "http://www.example.com/", quale risorsa sto chiedendo? La risorsa dell'indice?
Il pattern di risorse del sito web RESTful più comune che vedo è aggiungere una vista all'URI:
/ resourcetype / identifier [/ view] [/ page] [?filterparams]
Quando non ci sono view , devi semplicemente servire una vista predefinita. Nel tuo caso:
example.com restituisce la vista predefinita per la risorsa di primo livello, il tuo sito web. aboutus potrebbe essere un identificatore denominato per una risorsa nell'ambito del CMS di primo livello. * Detto questo, a volte è meglio fudge un po 'per una semantica migliore. Ad esempio, StackOverflow utilizza le / domande / [id] RESTful per domande, ma la domanda pagina è / questions / ask che non è molto RESTful ( ask non è una risorsa questions ) ma ha molto senso usare semplici mortali.
* Nei CMS al livello più alto, il tipo di risorsa è spesso, ma non sempre, rimosso perché è ridondante.
Tenere presente che il progetto RESTful di per sé è inteso a fornire uno standard in base al quale il web diventa programmabile in modo uniforme. Non è sempre appropriato o utile calzare il corno dell'intero sito web umano in pura semantica REST.
Quando hai risorse, considerare le loro rappresentazioni è utile. È inoltre importante considerare gli altri principi di progettazione di REST, come gli statelessnes, e il loro impatto sulle prestazioni e sull'usabilità del tuo sito web. Ma ricorda che REST è uno strumento, non un obiettivo. È un mezzo, non una fine.
Usa la semantica RESTful dove utile , dopo aver compreso i loro scopi e benefici, e non preoccuparti se il tuo sito non è perfettamente RESTful. Sarebbe quasi impossibile per qualsiasi sito non banale in ogni caso.
TL; DR : REST è uno strumento. Usalo quando e dove è utile ma non essere vincolato da esso.
But, what about an "about us" page[?] What kind of resource is that?
Complex. Niente di male in una risorsa con componenti, pezzi o struttura.
Le risorse non sono "righe di database relazionali" o altre cose atomiche. Sono risorse.
I database orientati ai documenti gestiscono questo con più garbo perché una risorsa può essere più grande e più strutturata.
Is it even a resource in the RESTful sense of the word?
Sì.
Also, say I go to the URL "http://www.example.com/", what resource am I asking for?
No.
Stai chiedendo la risorsa "aboutus". È possibile (ma strano) che una risorsa sia un singleton. Nessun ID e non una "lista".
Restituisce un documento XML complesso con molti pezzi e parti. Niente di male in questo.
The index resource?
Non significa molto in senso "RESTful". La pagina "indice" è per le persone. Un'applicazione che utilizza un'API RESTful è progettata per richiedere tipi specifici di risorse.
Manterrei la mia vista indipendente dal back-end. Puoi chiedere al back-end risorse come la fisarmonica, la barra di navigazione e altri oggetti che riguardano il corpo. Tuttavia, dovresti lasciare l'elaborazione di queste rappresentazioni di risorse al tuo codice cliente, che alla fine le renderà conformi ai requisiti.
La risorsa per "Chi siamo" è ... Us :) er, Tu. Pensa agli attributi di Te che vuoi pubblicizzare e arrotoli come un sostantivo con una rappresentazione.
Questi valori non devono provenire da un database ... probabilmente saranno un mucchio di valori stringa, e quelli possono provenire dalla configurazione, o forse persino codificati in una classe.
Leggi altre domande sui tag web-development rest web-applications http web