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

AFAIK Fielding didn't claim REST was any good, he was just describing the de-facto architecture of the web.

Questo lo sottovaluta un po ', penserei. REST è, dopo tutto, un'enumerazione dello stile architettonico che Fielding stava usando come capo architetto del specifica HTTP / 1.1 .

But is there actually any reason to think REST is a desirable architecture for this domain? Is there any evidence that say HATEOAS is a beneficial design principle for machine-to-machine communication?

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

By applying the software engineering principle of generality to the component interface, the overall system architecture is simplified and the visibility of interactions is improved. Implementations are decoupled from the services they provide, which encourages independent evolvability. The trade-off, though, is that a uniform interface degrades efficiency, since information is transferred in a standardized form rather than one which is specific to an application's needs. The REST interface is designed to be efficient for large-grain hypermedia data transfer, optimizing for the common case of the Web, but resulting in an interface that is not optimal for other forms of architectural interaction.

Quindi pensiamo per un momento a cosa significa questo. Quando ho problemi con il mio router wireless, posso comunicare con lo stesso browser che uso per inviare risposte a stackexchange. In particolare, non importa quale browser sto usando, o se il mio browser è qualche aggiornamento dietro (o avanti) di ciò che il router si aspetta. 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 solo .

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

That doesn’t mean that I think everyone should design their own systems according to the REST architectural style. REST is intended for long-lived network-based applications that span multiple organizations. If you don’t see a need for the constraints, then don’t use them.

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

Quando la macchina da macchina diventa difficile, è che hai perso la capacità dell'essere umano di confondere la semantica fornita dalle rappresentazioni. I clienti possono cavarsela sapendo solo i tipi di media, ma normalmente abbiamo un essere umano che osserva i segnali semantici per ricavare significato.

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

Ma è lavoro; devi investire nello sviluppo di rappresentazioni compatibili con le macchine delle tue risorse e assicurarti che tali rappresentazioni rimangano compatibili in avanti e all'indietro, in modo che i clienti possano essere sviluppati indipendentemente.

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

No, "REST completo" non è eccezionale.

Come dimostra la mancanza di persone che implementano HATEOS nelle loro API e gli infiniti argomenti su cui verbo HTTP usare per una particolare chiamata.

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

Avere queste cose in funzione e poi spiegarle ai consumatori dell'ap è stato un compito difficile. "perché non faccio un GET con l'id che voglio nella stringa di query e mi mandi i dati?" era una domanda ovvia e comune.

Quindi il secondo problema era l'XML, javascript non l'aveva capito, gli schemi erano un rompicoglioni e avresti finito con enormi file txt composti per lo più da <MyLongObjectName> . Quindi le persone hanno iniziato a utilizzare JSON.

Ora REST ha un po 'di culto attorno ad esso, ma poiché le regole sono così vaghe non ti impedisce di abbattere un'API utilizzabile, che è abbastanza semplice da permettere ai consumatori di "accedervi" e usarla senza un 6 mese di imbarco.

Si noti che Roy non è stato l'inventore originale della maggior parte dei principi di REST, mette insieme molti principi noti per funzionare nei sistemi precedenti per risolvere vari problemi specifici. REST è semplicemente la naturale conclusione dell'applicazione di questi principi in una singola architettura.

Anche prima che Roy Fielding scrivesse la sua tesi su REST , l'HTTP era già progettato attorno ai principi che in seguito diventeranno noti come REST. Nella conclusione della sua tesi di laurea , ha scritto:

At the beginning of our efforts within the Internet Engineering Taskforce to define the existing Hypertext Transfer Protocol (HTTP/1.0) [19] and design the extensions for the new standards of HTTP/1.1 [42] and Uniform Resource Identifiers (URI) [21], I recognized the need for a model of how the World Wide Web should work. This idealized model of the interactions within an overall Web application, referred to as the Representational State Transfer (REST) architectural style, became the foundation for the modern Web architecture, providing the guiding principles by which flaws in the preexisting architecture could be identified and extensions validated prior to deployment.

REST e HATEOS si adattano bene al problema per cui è stato progettato:

REST is a coordinated set of architectural constraints that attempts to minimize latency and network communication while at the same time maximizing the independence and scalability of component implementations. This is achieved by placing constraints on connector semantics where other styles have focused on component semantics. REST enables the caching and reuse of interactions, dynamic substitutability of components, and processing of actions by intermediaries, thereby meeting the needs of an Internet-scale distributed hypermedia system.

Tuttavia, va notato che Web e REST non sono necessariamente adatti per ogni problema:

Likewise, proposed extensions can be compared to REST to see if they fit within the architecture; if not, it is more efficient to redirect that functionality to a system running in parallel with a more applicable architectural style.

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 riadattandoli ai vincoli del web, in realtà avrebbero dovuto essere i servizi web in primo luogo.

Ci sono molte API che in realtà non si adattano a REST. Le API che non hanno bisogno del tipo di scalabilità che REST è progettato per risolvere, non sono consumate da più organizzazioni che possono evolversi indipendentemente e non hanno bisogno di essere longeve; per questi problemi, i vincoli REST sono solo una camicia di forza.

But is there actually any reason to think REST is a desirable architecture for this domain? More specifically, is there any evidence that say HATEOAS is a beneficial design principle for machine-to-machine communication?

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

Nella presentazione di Fielding su Adobe Experience Manager:

REST is NOT an architecture!

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

REST is an accumulation of design constraints to induce architectural properties

REST è una parola chiave e tutti vogliono avere l'API RESTful. In realtà, quando le persone si trovavano di fronte a vincoli REST, lasciavano cadere alcuni di questi vincoli perché non erano necessari o non si ottenevano vantaggi 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 per progettare un'applicazione del genere, tanto che, ad esempio, il team di app per dispositivi mobili e il team di back-end hanno appena accettato di abbandonare tale vincolo. E questo tipo di ha senso perché entrambi i team non sono così accoppiati perché lavorano per la stessa compagnia.

REST in AEM

se quello che vuoi è creare un servizio che è consumato da un altro server, allora xmlrpc è la scelta giusta. Se quello che vuoi è un servizio che deve essere consumato da thin client o dispositivi a basso consumo .. o client sconosciuti su Internet aperto, forse prendi in considerazione il resto usando json. Ma ricorda, JSON è una notazione inferiore per specificare i dati generali, rispetto a xml.