Bene, ci sono molti modi per imparare a creare un'applicazione Web RESTful e no, non esiste un modo giusto unico. RESTful non è uno standard ma utilizza un set di standard (HTTP, URI, Mime Type, ...).
Inizia con questo: come ho spiegato REST a mia moglie
Quindi, procedere con questo: RESTful Web Services Cookbook
E poi fai tutto il possibile per sviluppare applicazioni web perché il modo migliore per imparare è fare esperimenti e puoi imparare così tanto dai tuoi errori;)
Non preoccuparti se le tue prime app web non saranno completamente RESTful: troverai il modo di farlo!
Quindi, citando Obi-Wan Kenobi, "possa la forza essere con te!" ;)
MODIFICARE
Ok, lasciami essere più specifico.
Vuoi creare qualche webapp RESTful, eh? Bene, come ho detto, ci sono molti modi per farlo, ma questa è la linea guida principale.
Definizione
REST (Representational State Transfer) è uno stile di architettura software per sistemi distribuiti (come il WWW). Non è uno standard ma utilizza un insieme di standard: HTTP, AJAX, HTML, URI, Mime Type, ecc. Stiamo parlando della rappresentazione di una risorsa, non di una risorsa stessa. Tratto da "Come ho spiegato REST a mia moglie":
Moglie : una pagina web è una risorsa?
Ryan : Un po '. Una pagina Web è una rappresentazione di una risorsa. Le risorse sono solo concetti.
Vincoli di architettura
- Client-Server : client e server sono separati dall'interfaccia uniforme (descritta di seguito).
- Stateless : la comunicazione server-client viene eseguita senza salvare un determinato stato client sul server.
- Cachable : il client potrebbe avere una cache di risposte di richieste già fatte.
- Sistema a strati : il client non sa se è direttamente collegato a un end-server o se la comunicazione avviene tramite intermedi.
Interfaccia uniforme
- Identificazione delle risorse: ogni risorsa deve essere identificata da un URI.
- Protocollo : per entrare in comunicazione client e server, un protocollo deve essere fatto prima. Ogni richiesta potrebbe avere il giusto tipo MIME (application / xml, text / html, application / rdf + xml, ecc.), Le intestazioni giuste e il giusto metodo HTTP (vedere la descrizione CRUD di seguito).
CRUD
Ok, abbiamo visto che per identificare le risorse possiamo usare l'URI, ma abbiamo bisogno di qualcos'altro per le azioni (aggiungi, modifica, cancella, ecc.): Un grande benvenuto in CRUD (Crea, Leggi, Aggiorna ed Elimina).
- Crea { HTTP: POST } { SQL: INSERT } => crea una nuova risorsa
- Leggi { HTTP: GET } { SQL: SELECT } => ottieni una risorsa
- Aggiorna { HTTP: PUT } { SQL: UPDATE } => modifica una risorsa
- Elimina { HTTP: DELETE } { SQL: DELETE } => elimina una risorsa
Ora, riguardo a PUT e DELETE, potrebbero apparire alcuni problemi tecnici (li otterrai con il modulo HTML): spesso gli sviluppatori bypassano questo problema usando POST per ogni richiesta 'PUT' e 'DELETE'. Ufficialmente, devi usare PUT e DELETE. A proposito, fai quello che vuoi. La mia esperienza mi spinge a usare POST e GET ogni volta.
--- La parte successiva dovrebbe essere usata ma non è un'obbligazione REST: riguarda i dati collegati ---
URI
URI astratto dai dettagli tecnici! Dì addio all'URI come segue:
http://www.example.com/index.php?query=search&id=9823&date=08272012
Riprogettare l'URI! Prendi il link sopra e modificalo come segue:
http://www.example.com/search/2012/08/27/9823
Va molto meglio, eh? Potrebbe essere fatto da:
Un'altra cosa: utilizzare URI diversi per rappresentare risorse diverse:
Fai attenzione : about.html e about.rdf non sono file! Potrebbero essere il risultato di una trasformazione XSLT!
Negoziazione del contenuto
Se hai raggiunto questo punto, congratulazioni! Probabilmente, sei pronto per ottenere concetti più astratti perché stiamo entrando nei dettagli tecnici del Web semantico;) Bene, quando il tuo cliente desidera una risorsa, in genere effettua la seguente richiesta:
GET http://www.example.com/about
Accept: application/rdf+xml
Ma il server non risponderà con about.rdf perché ha un URI diverso ( http://www.example.com/about.rdf ). Quindi, diamo un'occhiata al modello 303 ! Il server restituirà questo:
303 See Other
Location: http://www.example.com/about.rdf
E il client seguirà il link restituito come segue:
GET http://www.example.com/about.rdf
Accept: application/rdf+xml
Infine, il server restituirà la risorsa richiesta:
200 OK
about.rdf
Non preoccuparti: l'applicazione client non farà nulla di tutto questo! Il modello 303 deve essere eseguito dall'applicazione server e il browser farà il resto;)
Conclusione
Spesso la teoria è molto, molto lontana dalla pratica. Sì, ora sai come progettare e sviluppare un'applicazione RESTful ma la linea guida sopra è solo un suggerimento. Troverai il tuo modo migliore per creare applicazioni web e probabilmente non sarà lo stesso che la teoria vuole. Non gliene frega niente: D!
Bibliografia
Servizi Web RESTful, Sameer Tyagi
Le API REST devono essere guidate dall'ipertesto, Roy Thomas Fielding
Servizi Web RESTful: le basi, Alex Rodriguez
Flusso di lavoro REST Webber