È la semantica della parte integrale dei dati di REST?

Question

Questo è un follow-up su una questione chiedendo spiegazioni di REST .

Come si può vedere dai commenti alla mia risposta, abbiamo avuto una piccola discussione con Darrel Miller sulla migliore rappresentazione mediatica delle risorse. Abbiamo avuto un ulteriore discussione e-mail che ha portato a questa domanda.

La differenza principale tra Darrel di e la mia comprensione del REST è se la semantica dei dati è parte della API REST.

Darrel crede (la mia interpretazione delle sue parole :-)) che la semantica dei dati è una parte essenziale delle API REST e come tale, il prescelto rappresentazione mediatica dovrebbe rifletterla. Così, una vera e propria API REST deve scegliere:

• un supporto ben note come ATOM per rappresentare i dati, in modo che il maggior numero di clienti potrebbero comprendere la semantica della risorsa in modo nativo;
• un tipo di supporto specifico per app come application / vdn.mycomany.mymedia e si aspettano il cliente a capire questo tipo di supporto per essere in grado di consumare i dati sulle risorse. Application / xml non è una buona rappresentazione della risorsa, in quanto non rappresenta la semantica del tipo di supporto, ma richiede al cliente di sapere di più sulla semantica.

I, d'altra parte, ritengo che l'API REST è uno strato separato dalla rappresentazione dati effettivi. Il tipo di supporto esposta dal API è solo un contenitore per trasferire i dati di risorsa. La semantica effettiva dei dati viene trattata separatamente. Così, un client che non capisce i dati, può ancora consumare l'API REST. Application / xml è davvero un buon rappresentazione dei dati, in quanto consente l'accoppiamento stretto per i clienti che capiscono lo schema, ma permette comunque client che non capisco lo schema per fare un po 'di elaborazione di base delle risorse.

Così, la domanda : è la parte dei dati semantica delle API REST? Dovremmo scegliere solo i tipi di supporto per la rappresentanza delle risorse che in realtà rappresentano la semantica dei dati così?

Vorrei appreaciate se la gente pubblica nelle loro risposte alcune citazioni, preferibilmente dal Roy uomo stesso. : -)

Answer 1

Partiamo dall'inizio: tipi di media sono lì per fornire al cliente con un formato che può utilizzare per decidere cosa fare dopo. Senza una pagina html, il browser non ha alcun legame dove andare. Senza un renderer HTML, il browser non può rendere una pagina e non si sa cosa fare.

Senza un tipo di supporto, il cliente non ha idea se sarà in grado di fare qualsiasi cosa con il flusso di byte. In effetti, quando un cliente riceve le intestazioni che specificano application / xml, che non è a conoscenza di cosa fare al di là di ottenere un parser XML.

Quindi la domanda è in realtà, se il cliente sia in grado di prendere una decisione in base al messaggio http senza avere uno sguardo all'interno del messaggio, o dovrebbe andare a sbirciare all'interno del messaggio (o peggio, analizzare il messaggio prima) a sapere cosa fare.

La mancanza di tipi di media significa che il cliente dovrà fare il lavoro Sbirciare aggiuntivo, o un processo peggio il corpo entità stessa, prima di poter prendere una decisione, sia per il rendering o alla trasformazione. A questo punto è necessario aggiungere un sacco di comportamento personalizzato per ognuno dei vostri formati si consiglia di trattare, e si perde un po 'di accoppiamento nel processo.

E 'anche un http fondamentale che gli intermediari devono essere in grado di elaborare le richieste senza ispezionare il corpo, e anche lì application / xml è problematico.

Ora, quando si dice che la semantica dei tipi di media fa parte o meno delle API ... ciò che costituisce l'API?

Dal punto di vista del cliente, non v'è alcuna API. V'è una rappresentazione iniziale che consente al client di prendere una decisione su cosa fare dopo. Il tipo di supporto è infatti in cui il cliente riceve le informazioni necessarie per navigare il "API", e come tale non ci può essere alcuna API senza rappresentazioni.

Inoltre, un cliente dovrebbe avere solo tre bit di conoscenza: un percorso bootstrap, il protocollo HTTP e i tipi di supporto. Il primo è solo un URI e non trasmette molto al di là della posizione di un represetnation necessario per continuare. Il secondo ha già semantica molto chiare. Il terzo è quello in cui si ha il controllo, in quanto è il contratto che avete con il vostro cliente.

Questo contraact dice che ogni volta che si vuole fare qualcosa, la cosa avrà la semantica:. Per aggiungere un cliente, inviare un application / xml + vnd.acme.customer a / i clienti utilizzando un POST

Da qui la mia risposta: la progettazione di un'architettura REST si basa su due fasi: modellazione delle risorse (a livello concettuale) e il tipo di supporto dell'edificio. Tutto il resto e si sta probabilmente facendo male.

Answer 2

Non vedo la necessità di essere eccessivamente pedanti su di esso. Una risorsa può esporre molteplici rappresentazioni; ciascuna con le proprie semantica (e anche molteplici dimensioni di semantica a quello). Se una rappresentazione non fornisce la semantica richieste da un particolare caso d'uso, esporre quello che fa.

  

In questo modo, un cliente che non lo fa   comprendere i dati, possono ancora consumare   REST API.

Non sono sicuro che sia una buona cartina di tornasole per quello che fa o non fa una rappresentazione decente. A cosa serve un client in grado di consumare un documento, ma non capisco abbastanza bene per fare qualsiasi cosa con esso? Credo non capisco come "trattamento di base delle risorse" rende application / xml una scelta migliore rispetto ad alcune blob arbitraria di 1 e 0?

Dal momento che hai chiesto per i riferimenti, Ecco un articolo di Roy Fielding dove "propone" una rappresentazione bitmap di grafici social network . Posso certamente ottenere una macchina per visualizzare questi bitmap, ma a che serve è che se non capisco il grafico sottostante social network? Sarebbe cambiare la rappresentazione di application / xml consentire a un client ingenuo per estrarre ulteriore significato da esso che non è contenuto nella bitmap? No..

Answer 3

questo serie di diapositive da Mark Baker maggiori spiegazioni sul perché application / xml non soddisfa il vincolo "auto-descrizione". È inoltre possibile leggere un numero di posti sul suo blog tra cui questo uno dove continua a spiegare perché application / xml + namespace non è equivalente al tipo di media.