Qual è il modo corretto di fare REST?


36

Oggi tutti fanno SOA , anche se alcuni in realtà non capiscono di cosa si tratta. Quindi hanno sbagliato. Usandolo come analogia, so cos'è REST (o almeno penso di farlo) e voglio farne parte. Ma voglio farlo bene.

Quindi la mia domanda è qual è il modo corretto di fare REST?


1
Il tag 'rest' di Stack Overflow wiki sembra essere il più vicino possibile alle risorse canoniche nel contesto della rete di scambio di stack
moscerino

17
Ho appena chiuso gli occhi per un po '... forse andare a fare un giro in bicicletta e poi sdraiarmi.
Edward Strange,

REST non sta fondamentalmente solo usando un URL come mydomain.com/accounts e un verbo HTTP per invocare un'operazione? Dove il verbo indica se si desidera ottenere, creare, aggiornare o eliminare i dati? Quando penso a REST è quello che penso.
The Muffin Man,

2
@Nick, questa è l'interpretazione più comune, la 'cosa reale' è molto più difficile da grok e (per quanto posso dire) molto più difficile da trovare effettivamente implementata ovunque ... (vedi la risposta di Wilk)
Benjol

3
@Nick la tua comprensione non è REST, è RPC su HTTP .

Risposte:


30

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


1
Potresti considerare di aggiungere questo link , che è la guida più completa che abbia mai incontrato.
Benjol,

Ho visto PUT e POST usati con i loro significati scambiati (in relazione alla tua risposta): POST -> crea, PUT -> aggiorna. Qualche idea su quale significato sia maggiormente utilizzato?
Andres F.

@Andres F .: jcalcote.wordpress.com/2008/10/16/… dice: Create = PUT iff stai inviando il contenuto completo della risorsa specificata (URL). Crea = POST se si sta inviando un comando al server per creare un subordinato della risorsa specificata, usando un algoritmo sul lato server. Update = PUT iff stai aggiornando il contenuto completo della risorsa specificata. Aggiornamento = POST se si richiede al server di aggiornare uno o più subordinati della risorsa specificata.
Wilk,

@ Benjol: ho intenzione di modificare con il tuo suggerimento;) Grazie!
Wilk,

1
@Wilk Alcune cose da considerare! Probabilmente perché nessuno ha ragione: P
Andres F.

5

un libro biblico REST o qualcosa del genere ....

Nessun libro biblico necessario; Avevo le stesse domande esatte e ho imparato tutto ciò di cui avevo bisogno o che volevo sapere su REST leggendo questi tre articoli:

  1. Introduzione per principianti a HTTP e REST da Net Tuts +
  2. Servizi Web RESTful: le basi di IBM developerWorks
  3. HTTP RESTful in pratica da InfoQ

Ma voglio farlo bene.

Come leggerai negli articoli sopra, la chiave è pensare ai pezzi accessibili della tua applicazione come "risorse" che possono essere create, recuperate, aggiornate o eliminate usando i "verbi" HTTP esistenti: GET, PUT, POST , ELIMINA.

Inoltre, conosci la differenza tra PUT e POST e quando utilizzarli. OTTENERE, PUTARE ED ELIMINARE dovrebbero essere transazioni idempotenti, POST no.

Inoltre, utilizzare correttamente i codici di stato HTTP quando si comunica al client.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.