REST e HATEOAS sono una buona architettura per i servizi web?

Se ho capito bene, REST è stato formalizzato da Roy Fielding come modello descrittivo dell'architettura del web. AFAIK Fielding non ha affermato che REST fosse utile, stava solo descrivendo l'architettura di fatto del web. La rete aveva già dimostrato a questo punto un enorme sistema ipertestuale distribuito di successo, quindi questo tipo di convalida REST come architettura di successo per il dominio dell'ipermedia distribuito principalmente navigato e consumato dagli umani.

I servizi Web REST sono stati creati applicando l'architettura REST alle API. Ma c'è davvero qualche ragione per pensare che REST sia un'architettura desiderabile per questo dominio? Più specificamente, ci sono prove che affermano che HATEOAS è un principio di progettazione vantaggioso per la comunicazione da macchina a macchina?

La mia preoccupazione è che HATEOAS abbia senso per l'hypermedia perché ci sono pochi tipi di contenuto ben noti (HTML, immagini, video ecc.) E il cliente sa come consumarli. Ma per le API i tipi di contenuto sono molto specifici e possono essere consumati in modo significativo dal client solo se il client è specificamente programmato per consumarli. La restituzione di un URL al client non rende di per sé il client in grado di consumare la risorsa indicata.

AFAIK Fielding non ha affermato che REST fosse utile, stava solo descrivendo l'architettura di fatto del web.

Ciò lo sottolinea un po ', penso. Dopotutto, REST è un elenco dello stile architettonico che Fielding stava usando come capo architetto delle specifiche HTTP / 1.1 .

Ma c'è davvero qualche ragione per pensare che REST sia un'architettura desiderabile per questo dominio? Esistono prove che affermano che HATEOAS è un principio di progettazione vantaggioso per la comunicazione da macchina a macchina?

"Dipende". HATEOAS fa parte del vincolo di interfaccia uniforme di REST.

Applicando il principio di ingegneria del software di generalità all'interfaccia del componente, l'architettura generale del sistema è semplificata e la visibilità delle interazioni è migliorata. Le implementazioni sono disaccoppiate dai servizi che forniscono, il che incoraggia un'evoluzione indipendente. Il compromesso, tuttavia, è che un'interfaccia uniforme degrada l'efficienza, poiché le informazioni vengono trasferite in una forma standardizzata piuttosto che in una specifica delle esigenze di un'applicazione. L'interfaccia REST è progettata per essere efficiente per il trasferimento di dati ipermediali di grandi dimensioni, ottimizzando per il caso comune del Web, ma dando come risultato un'interfaccia non ottimale per altre forme di interazione architettonica.

Quindi pensiamo per un momento a cosa significa. Quando ho problemi con il mio router wireless, posso comunicare con esso usando lo stesso browser che utilizzo per inviare risposte a stackexchange. In particolare, non importa quale browser sto utilizzando o se il mio browser presenta alcuni aggiornamenti (o successivi) rispetto alle aspettative del router. Non importa che l'organizzazione di ingegneria che ha scritto il browser sia completamente indipendente dall'organizzazione che ha creato l'interfaccia del router.

Funziona e basta .

Non è, ovviamente, universale. Fielding, nel 2008 , ha scritto:

Ciò non significa che penso che tutti dovrebbero progettare i propri sistemi secondo lo stile architettonico REST. REST è destinato ad applicazioni di rete di lunga durata che si estendono su più organizzazioni. Se non vedi la necessità dei vincoli, non utilizzarli.

I vincoli che formano lo stile architettonico REST sono stati scelti per le proprietà che inducono; se quelle proprietà non sono utili per il tuo caso d'uso, allora dovresti assolutamente considerare di eliminare i vincoli corrispondenti.

Dove la macchina alla macchina diventa difficile, è che hai perso la capacità dell'essere umano di sfocare la semantica fornita dalle rappresentazioni. I clienti possono cavarsela conoscendo solo i tipi di media, ma normalmente abbiamo un essere umano che guarda gli spunti semantici per ricavarne un significato.

schema.org è una parte dello sforzo di creare un vocabolario leggibile automaticamente; gli agenti macchina usano il client per trovare i suggerimenti semantici e applicano la propria comprensione del significato per scegliere le azioni corrette da intraprendere.

Ma è lavoro; è necessario investire nello sviluppo di rappresentazioni a misura di macchina delle proprie risorse e garantire che tali rappresentazioni rimangano compatibili in avanti e all'indietro, in modo che i clienti possano essere sviluppati in modo indipendente.

Quando una singola organizzazione controlla sia il client che il server, i vantaggi di questa indipendenza sono molto più piccoli, nel qual caso il vincolo potrebbe non essere una scelta architettonica appropriata.

No, "REST completo" non è eccezionale.

Come evidenziato dalla mancanza di persone che implementano HATEOS nelle loro API e dagli infiniti argomenti su quale verbo HTTP utilizzare per una determinata chiamata.

Ma devi riconoscere perché REST è così popolare. Prima della sua adozione c'erano vari protocolli complicati e folli come ebXML e SOAP che comprendevano riconoscimenti, timeout, ID di conversazione e stato.

Mettere in moto queste cose e poi spiegarle ai consumatori dell'API è stato un compito difficile. "Perché non faccio semplicemente GET con l'id che desidero nella stringa di query e mi invii i dati?" era una domanda ovvia e comune.

Quindi il secondo problema era XML, javascript non lo capiva, gli schemi erano un dolore nel culo e finivi con enormi file txt costituiti principalmente da <MyLongObjectName>. Quindi le persone hanno iniziato a usare JSON invece.

Ora REST ha un po 'di culto attorno ad esso, ma poiché le regole sono così vaghe non ti impedisce di mettere a tacere un'API utilizzabile che è abbastanza semplice da consentire ai consumatori di "prenderla" e utilizzarla senza un mese di imbarco processi.

È da notare che Roy non è stato l'inventore originale della maggior parte dei principi di REST, mette insieme molti principi che sono noti per funzionare in sistemi precedenti per risolvere vari problemi specifici. REST è semplicemente la naturale conclusione dell'applicazione di questi principi in un'unica architettura.

Anche prima che Roy Fielding scrivesse la sua tesi su REST , l'HTTP era già stato progettato attorno ai principi che in seguito sarebbero stati conosciuti come REST. A conclusione della sua tesi , scrisse:

All'inizio dei nostri sforzi nell'ambito della Task Force di ingegneria di Internet per definire l'attuale Hypertext Transfer Protocol (HTTP / 1.0) [19] e progettare le estensioni per i nuovi standard di HTTP / 1.1 [42] e Uniform Resource Identifier (URI) [21 ], Ho riconosciuto la necessità di un modello di come dovrebbe funzionare il World Wide Web. Questo modello idealizzato delle interazioni all'interno di un'applicazione Web complessiva, indicato come stile architettonico REST (Representational State Transfer), divenne il fondamento della moderna architettura Web, fornendo i principi guida attraverso i quali si potevano identificare i difetti nell'architettura preesistente ed estensioni convalidato prima della distribuzione .

REST e HATEOS si adattano perfettamente al problema per cui sono stati progettati:

REST è un insieme coordinato di vincoli architetturali che tenta di minimizzare la latenza e la comunicazione di rete, massimizzando allo stesso tempo l'indipendenza e la scalabilità delle implementazioni dei componenti . Ciò si ottiene ponendo vincoli sulla semantica del connettore in cui altri stili si sono concentrati sulla semantica dei componenti. REST consente la memorizzazione nella cache e il riutilizzo delle interazioni, la sostituibilità dinamica dei componenti e l'elaborazione delle azioni da parte degli intermediari , soddisfacendo così le esigenze di un sistema ipermediale distribuito su scala Internet.

Tuttavia, va notato che il Web e il REST non sono necessariamente adatti a tutti i problemi:

Allo stesso modo, le estensioni proposte possono essere confrontate con REST per vedere se si adattano all'interno dell'architettura; in caso contrario, è più efficiente reindirizzare tale funzionalità a un sistema in esecuzione in parallelo con uno stile architettonico più applicabile.

Quindi se la tua domanda è "REST e HATEOAS sono una buona architettura per i servizi web?" quindi, la risposta è semplicemente "sì, è una buona architettura per i servizi web". Il problema è davvero se tutti i problemi che le persone hanno cercato di risolvere adattandoli ai vincoli del web, in realtà avrebbero dovuto essere i servizi web in primo luogo.

Esistono molte API che non rientrano realmente in REST. Le API che non hanno bisogno del tipo di scalabilità che REST sono progettate per risolvere, non sono utilizzate da più organizzazioni che potrebbero evolversi in modo indipendente e non necessitano di lunga vita; per questi problemi, i vincoli REST sono solo una camicia di forza.

Ma c'è davvero qualche ragione per pensare che REST sia un'architettura desiderabile per questo dominio? Più specificamente, ci sono prove che affermano che HATEOAS è un principio di progettazione vantaggioso per la comunicazione macchina-macchina?

La prova è il successo del Web nel risolvere i problemi di molte persone. REST è un'architettura ibrida, che combina i disegni di molti stili architettonici precedenti. Molti domini problematici non hanno tutti i requisiti del Web e non devono obbedire a tutti i vincoli di REST per funzionare bene. Ecco perché ci sono molte architetture di successo che funzionano bene applicando solo alcune parti di REST ma non le altre. HATEOAS e Uniform Interface, ad esempio, sono principi che spesso vengono ignorati dalle API che non devono attraversare confini e sistemi organizzativi con un periodo di ammortamento relativamente breve.

Nella presentazione di Fielding su Adobe Experience Manager:

REST NON è un'architettura!

Il riposo è uno stile architettonico, che è l'astrazione di diverse architetture esistenti su Internet.

REST è un accumulo di vincoli di progettazione per indurre proprietà architettoniche

REST è una parola d'ordine e tutti vogliono avere l'API RESTful. In realtà, quando le persone hanno affrontato i vincoli REST, hanno abbandonato alcuni di questi vincoli perché non c'era bisogno o nessun beneficio da ottenere per loro di applicare tutti i vincoli.

Come hai detto, HATEOAS è utile quando il client è un browser web. Quando il client è un'app mobile, forse non così tanto. Sarebbe una buona pratica, ma ci sono anche dei costi associati alla progettazione di un'applicazione del genere, al punto che, per fare un esempio, il team di app mobili e il team di back-end hanno appena accettato di eliminare questo vincolo. E questo tipo di senso ha senso perché entrambe le squadre non sono così vagamente accoppiate perché lavorano per la stessa azienda.

RESTO in AEM

se quello che vuoi è creare un servizio che viene utilizzato da un altro server, allora xmlrpc è la scelta corretta. Se quello che vuoi è un servizio che può essere consumato da thin client o dispositivi a bassa potenza ... o da client sconosciuti su Internet aperto, forse considera il riposo usando json. Ma ricorda, json è una notazione inferiore per specificare i dati generali, rispetto a XML.