Differenza tra implementazioni REST e HTTP REST

Supponendo di avere una semantica standardizzata e ben definita per ogni azione, e che le azioni non siano estendibili dagli utenti del protocollo e assumendo che la semantica dei protocolli sia tale da poter costruire componenti a strati che capiscano queste semantiche, e che puoi costruire un client generico che può essere riproposto per adattarsi a qualsiasi applicazione senza modifiche al protocollo, quindi sì, è possibile che possano essere REST in linea di principio, ma non HTTP REST.

Tuttavia, l'API che hai descritto non sta facendo una chiara distinzione tra i metadati REST (ad esempio l'identificatore di risorse) ai dati effettivi. Una versione migliorata che rende questa distinzione ovvia (e più conforme a "Uniform Interface") potrebbe essere:

POST http://example.com/api
{ 
  "action": "fetch", 
  "resource": {"name": "book", "id": "5"}
}

POST http://example.com/api 
{ 
  "action": "create", 
  "resource": {"name": "book", "id": "5"},
  "title": "Jack and the Beanstalk", 
  "Author": "John Smith" 
}

In questo sistema REST, l'interfaccia uniforme è un dizionario invece di una stringa URI. Proprio come l'URI di HATEOAS, questi URI di dizionario dovrebbero essere considerati come identificativi opachi di qualsiasi risorsa all'interno del sistema. Considererei un URI del dizionario troppo complicato per il sistema di identità, ma in linea di principio non viola necessariamente REST.

Nota che né questo esempio né il tuo esempio originale dimostrano correttamente HATEOAS, che funziona molto più a fondo nello stile architettonico di quanto la maggior parte delle persone realizzi.

Se si costruisce la propria architettura in seguito a REST, allora sì, è possibile creare un'API REST con le stesse proprietà di HTTP, senza utilizzare alcuna funzionalità HTTP. Tuttavia, dovresti davvero considerare il motivo per cui vorresti farlo, perché uno dei vantaggi di HTTP REST è che la standardizzazione ti consente di trarre vantaggio dal riutilizzo di componenti standardizzati esistenti.

An aspect of REST I am confused about separating REST principles and REST implementations.

Probabilmente il 99% delle persone è confuso. Le persone possono leggere su REST, ma quando si tratta di implementazione, è difficile trovare una buona implementazione di esempio RESTful. Uno dei motivi è che tutti chiamano le API API REST quando intendono realmente l'API HTTP.

In realtà, c'è un'implementazione di riferimento come menzionato da Roy, REST è stato ciò che li ha guidati nella costruzione dell'HTTP. Quindi, dovresti davvero guardarlo e capirlo. Non è semplice come capire che per recuperare devi usare GET e per crearlo dovresti usare POST. La cosa più importante è che le richieste GET sono memorizzabili nella cache e se si desidera avere un'implementazione API RESTful che dovrebbe essere memorizzabile nella cache, altrimenti l'API non sarà adatta per essere utilizzata sul Web.

Come GET /books/2 is used to fetch book resource #2 non è realmente il punto (come dovrebbero essere formati gli URL), il punto è che vuoi che quell'identificatore opaco sia memorizzato nella cache dopo che qualcuno lo ha scaricato. Può essere memorizzato nella cache se il dettaglio della richiesta è nel corpo? Quanto tempo dovrebbe essere memorizzato nella cache? Cosa succede se qualcuno lo aggiorna?

Un'altra cosa che rende difficile vedere cos'è REST perché è uno stile dell'architettura. Non è un'architettura, le diverse architetture possono avere lo stile REST. Trovo che la presentazione REST in AEM di Roy sia utile per interpretare cos'è REST.

Quando parli di un servizio web RESTful, devi separare tre problemi ortogonali:

1. "RESTfulness", vale a dire se l'architettura del servizio soddisfa o meno i vincoli stabiliti nella Fielding's Thesis (sembra che tu abbia una buona conoscenza di questo).
2. Il Web, ovvero se il tuo servizio è conforme e utilizza pienamente la semantica di HTTP (questo è ciò di cui sei confuso: un servizio può essere RESTful ma violare HTTP). Non c'è nulla di intrinsecamente non-RESTful sulla creazione di un servizio web interamente su POST , ma non è "webful", cioè non usa la semantica di HTTP e l'infrastruttura del web al suo pieno potenziale. Usare PUT per le operazioni che sono idempotenti significa che il client (e qualsiasi server proxy tra (!!!)) conosce per un fatto che può riprovare l'operazione senza conseguenze. L'utilizzo di GET per operazioni con effetti collaterali significa che il client (e qualsiasi server proxy tra) conosce per un fatto che può memorizzare nella cache e / o speculativamente la risorsa senza conseguenze.
3. Design URI, ad esempio l'aspetto dei tuoi URI. Per un servizio web RESTful, non dovrebbe importare quale sia il tuo URI, dal momento che HATEOAS dice che siamo solo seguenti link che ci vengono inviati dal server, non abbiamo mai aspetto a quei link. In altre parole: se ti stai chiedendo se i tuoi URI siano "RESTful", probabilmente il tuo servizio non lo è. Tuttavia , ci sono altri motivi di "RESTfulness" per preoccuparsi di come appaiono gli URI. Ad esempio, hackability (essere in grado di cambiare semplicemente l'URI per ottenere il risultato desiderato), SEO, perdita di informazioni (mantenendo i dati sensibili fuori dagli URI), o anche solo "bellezza".

Fai riferimento alla tesi Fielding come una "specifica" qui e in un'altra domanda correlata che non penso sia una descrizione appropriata. La tesi espone una serie di principi con cui hai chiaramente familiarità che ci aiutano a capire quanto bene una determinata architettura si adatti al modello REST. Potresti volerci un po 'di tempo per riesaminare la sezione 6 che parla di URI e HTTP e di come si riferiscono a questi principi. In particolare la sezione 6.2.5 Mismatch REST nell'URI e la sezione 6.3.4 Mismatch REST in HTTP potrebbe essere informativo come indicano come i principi di REST siano indipendenti da queste specifiche.

Quindi la risposta breve qui è che, sì, è possibile definire il proprio insieme di protocolli e standard e renderli allineati con REST. Il problema con questo, tuttavia, è che per essere utile, è necessario adottare questi standard. L'implementazione di un approccio in stile REST al di sopra del POST non produrrà quasi nessun beneficio. In particolare, il valore di un'interfaccia uniforme dipende dalla sua adozione. Quando ne definisci uno nuovo, per definizione, nessun altro può averlo adottato. È tecnicamente possibile (anche se altamente improbabile) che tu possa convincere la gente ad adottarlo in futuro, ma ciò non fa molto per te ora.

Invece quello che hai è un nuovo approccio che tunnels su HTTP. E come sottolinea Laiv nel suo commento, l'uso di POST per tutto va contro la struttura dell'infrastruttura WWW. È anche uno dei difetti fondamentali che ha portato al declino di WSDL / SOAP come standard di servizio Web dominante. L'altro principale è la mancanza di un'interfaccia uniforme e significativa.

is this still technically REST?

Questo non è, a mio avviso, un'utile definizione della domanda; con questo intendo che non è una domanda che ti chiederesti se non fossi confuso.

Questa confusione non è colpa tua - Fielding Non stava scrivendo per un pubblico generale .

My dissertation is written to a certain audience: experts in the fields of software engineering and network protocol design.

C'è molto, e con questo intendo un intero lotto , di letteratura scritta dal pubblico generale, che aggiunge considerevolmente alla confusione.

An aspect of REST I am confused about separating REST principles and REST implementations.

Esiste solo un'implementazione di REST che ha una parte significativa della mente: il World Wide Web. Fielding ( 5.1.5 )

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.

Potrebbe anche essere utile rivedere Fielding 6.5.2

What makes HTTP significantly different from RPC is that the requests are directed to resources using a generic interface with standard semantics that can be interpreted by intermediaries almost as well as by the machines that originate services. The result is an application that allows for layers of transformation and indirection that are independent of the information origin, which is very useful for an Internet-scale, multi-organization, anarchically scalable information system.

(corsivo aggiunto).

Ti incoraggerei anche a guardare il discorso di Richardson del 2008, La giustizia ci porterà milioni di intricate mosse .

The Internet is not a truck. When people in the 90s said "WWW" instead of "HTTP" they were on to something. HTTP is only one of the Web technologies, and it's not the most important one.

What the Web had going for it was two other technologies that had never been seen before. There was an addressing technology, the URI, which killed off the other Internet protocols.

And there was a hypertext markup language, HTML, which made it possible to put something entirely new on the Internet without inventing a new protocol.

Per capire REST penso che devi capire le alternative.

Ad esempio, guarda ebXML

link

Questo è solo un documento su come concordare un aggiornamento. e ha 10 volte il dettaglio della dissertazione di Fieldings.

La popolarità di REST non deriva dal rigore delle sue specifiche, o dai principi di un'architettura intelligente, ma dal senso comune di dire

"Hey, why don't we just send simple messages over HTTP like we do with our website?"