REST vs RESTful rispetto al servizio web "normale" - lo stesso o no?

Gli attributi chiave di un'applicazione RESTful sono: Tutte le comunicazioni sono via http GET, POST, PUT, DELETE E tutti gli elementi sono indirizzati tramite un URL standard del modulo http://your.site.com/salesapp/salesperson/0000001/details cioè solo un URL puro senza parametri, ecc. L'URL identifica la cosa GET, POST, PUT, DELETE identifica ciò che vuoi fare.

Il motivo principale per farlo è che hai automaticamente un servizio stateless che può essere bilanciato, fallito ecc. ecc.

L'assoluta semplicità dello schema rende l'interfaccia molto pulita, disaccoppiando totalmente il client da qualsiasi particolare implementazione back-end.

REST sta per Representational State Transfer. Se il tuo software è conforme ai vincoli REST , allora è considerato come RESTful.

Bene, ora che ho strappato spudoratamente da Wikipedia, cosa significa veramente? Significa in effetti utilizzare i comandi HTTP incorporati come GET, POST, PUT, DELETE e alcuni altri più rari per comunicare avanti e indietro tra un client e un server.

Quello che stai facendo sembra una sua app RESTFul. Tuttavia, c'è una differenza di grandi dimensioni tra servizi web RESTFul ben progettati e pili o junk. Ad esempio il codice PHP all'altra estremità del GET potrebbe eseguire cambiamenti di stato, che sarebbero considerati errati poiché un GET è visto come un'operazione di sola lettura. Ci sono sottili differenze tra come vengono usati anche POST (new) e PUT (replace).

L'articolo di Wikipedia su questo è veramente buono, quindi mi fermo qui.

Prima di andare oltre, questa domanda correlata potrebbe aiutarti

La differenza tra REST e RESTful è semplicemente semantica. REST è uno stile architettonico applicato a una relazione client-server. RESTful è semplicemente un modo per dire ai tuoi clienti che usi REST.

Molte applicazioni web affermano di essere RESTful, ma in realtà sono solo parzialmente conformi al REST vincoli (come ha fatto anche Martijn Verburg nella sua risposta). Li elenco solo qui ma ti invito vivamente a leggere l'articolo:

• client-server
• Cacheable
• Sistema a strati
• Codice su richiesta (facoltativo)

Dato che dici di lavorare sul lato client, potrebbe essere utile vedere che cosa un'architettura REST ti darà e si aspetta da te come client di connessione. Sebbene REST non sia HTTP, è di gran lunga il protocollo più popolare che supporta ciò che REST è, quindi creerò il mio esempio in merito.

Il tuo cliente dovrà:

• usa i verbi HTTP (ad esempio GET, POST, PUT, DELETE, OPTIONS, PATCH) per eseguire operazioni pertinenti
• offerta Accetta intestazioni e intendi intestazioni Content-Type (ad esempio ricevi un codice XML che non hai mai visto prima ma puoi utilizzare un XSD di riferimento per creare un modello di dominio sul lato client da presentare all'utente)
• segui i link offerti in un Content-Type che hai compreso (es. ottieni il tuo utente o la tua applicazione per dedurre che <link rel="pay" href="http://example.org/orders(1)/payment"> in HTML esprime una transizione di stato per creare una risorsa di pagamento attraverso un POST con un corpo contenente un XML che rappresenta il dettagli di pagamento come numero di carta di credito, importo e così via)
• reagisci correttamente alla vasta gamma di codici di stato HTTP

Se fa quanto sopra allora può essere pensato come un client REST, potresti chiamarlo "app RESTful", ma ciò significherebbe piuttosto che stai usando REST sul lato client che non è corretto quindi meglio evitare il termine.

RESTful significa che l'interfaccia è un insieme di oggetti, che possono essere letti e aggiornati (e possibilmente cancellati). Non ci sono interrogazioni multiparametriche (solo il parametro è l'oggetto che vuoi leggere) e c'è solo un tipo di operazione che cambia qualcosa sul server, caricamento di nuovo stato.

Queste limitazioni assicurano che tutte le richieste siano idempotenti (inviarle più volte non ha alcun effetto aggiuntivo sull'invio una volta). Questo è importante, perché la rete può fallire in qualsiasi momento e non fornire alcuna richiesta o risposta e con le richieste di identificazione basta inviarlo di nuovo e non è necessario eseguire un recupero complicato.