Servizi Web RESTful: tentativo di raggiungere HATEOAS con XML personalizzato

Question

Sto lavorando su un sistema aziendale che utilizzerà un servizio web RESTful tra client mobili e un server centrale. RESTful il più possibile, diciamo.

La mia domanda riguarda HATEOAS (hypermedia come motore dello stato dell'applicazione) e l'uso di xml personalizzato nei corpi di risposta HTTP.

Questo sistema sarà mai mai essere usato da clienti pubblici, ma mi piace l'idea hateoas di essere in grado di modificare il modello di allocazione delle risorse sul lato server in seguito senza dover riconfigurare ogni client in modo indipendente. Se decidiamo che a causa di problemi di ridimensionamento dobbiamo distribuire la funzione server su più box fisici, nessun problema, questo si rifletterà negli URI generati quando un client (o il server sotto istruzione da un client) crea una nuova risorsa .

Il nostro dominio aziendale è altamente specifico e insolito. Pertanto, vorrei utilizzare XML personalizzati per i corpi delle entità di risposta HTTP in tutto il servizio Web e il client analizzerà gli URI delle risorse al di fuori del codice xml per rimanere informato sulle posizioni delle risorse che può utilizzare quando modifica il proprio stato dell'applicazione. So che questo "rompe" la parte H di HATEAOS.

ad es. quando un cliente esegue la POST di una transazione sul server per l'elaborazione, il server potrebbe includere il seguente frammento xml nel corpo della risposta HTTP 201 (come parte di un documento xml più grande). Il server informerà anche il client dell'URI per la risorsa di transazione appena creata, ma questo probabilmente verrebbe incluso solo nell'intestazione dell'ubicazione HTTP.

<resulturi>http://resultserver/results/1234.xml</resulturi> 

È questo il modo male? Ci sono poche possibilità che i client che utilizzano questo servizio saranno sempre basati sul browser. Quali sono gli altri vantaggi di hypermedia rispetto alla consegna dell'uris come testo normale in xml?

Suppongo di poter passare a XHTML, ma il parser sulla nostra piattaforma mobile è molto più efficiente con POX.

Answer 1

Quello che stai facendo restituendo un url in resulturi è già ipermedia. L'unico problema è che è necessario un tipo di supporto che comunichi al client come viene formattata la risposta in modo che possa analizzare gli URL in modo prevedibile e documentato.

Opzione 1: Creare il proprio tipo di supporto come vnd.yourcompany.Resource + xml. In questo modo si sta affermando che il tipo di supporto può essere analizzato da un parser xml, ma segue alcune regole speciali definite dalla società. A questo punto puoi usare qualunque standard tu voglia per definire i collegamenti ipermediali (vedi domanda this). Un bel vantaggio è che se in 6 mesi decidi di dover apportare una modifica al formato del tuo XML, puoi creare una vnd.yourcompany.ResourceV2 + xml e fintanto che sei stato abbastanza intelligente da usare l'accetta- intestazione sui vecchi client, è possibile introdurre senza problemi il nuovo formato parallelamente a quello vecchio facendo in modo che le nuove applicazioni client accettino il nuovo formato.

Opzione 2: Sono solo seriamente serio su questa opzione, ma ho preso in considerazione l'idea di spingere per un nuovo tipo di media chiamato application/hyperxml + xml. Il documento seguirà le stesse regole di application/xml ma userebbe anche XLink per hypermedia. Ciò consentirebbe alle persone che utilizzano javascript di analizzare il documento XML per trarre vantaggio da hypermedia in modo standardizzato.

Opzione 3: Utilizzare XHtml. Non capisco perché il tuo parser abbia problemi con Xhtml, ma ti prendo in parola.

Answer 2

Ci sono due importanti informazioni che il server RESTful dovrà elaborare per le richieste, indipendentemente dal linguaggio di marcatura sottostante: un tipo di supporto e un URI. Supponendo che un tipo di supporto per un dato URI introduca l'accoppiamento client-server. Ad esempio, impedirebbe allo stesso URI di servire mai due tipi diversi di tipo di supporto.

XML non è l'unica opzione quando si progettano i formati hypermedia. Controlla lo Sun Cloud API, che definisce un'API REST hypertext-driven basata su JSON (anche se sembra non utilizzare il tipo di supporto con i relativi collegamenti ipertestuali). Non è difficile passare da questo approccio a uno che combina tipi di media con collegamenti ipertestuali.

Ad esempio, è possibile definire una struttura di dati JSON denominata Link simile a questa;

{ 
    "name":"human-readable label for link", 
    "uri":"http://example.com/resources/123", 
    "media_type":"application/vnd.com.example.Resource+json" 
} 

Answer 3

Hypermedia non richiede HTML o URI anche pienamente qualificati per quella materia. Se il tuo tipo di media definisce una regola per trasformare alcuni elementi della risposta in risorse de-referenceable, allora hai hypermedia.

<result>1234</result> 

L'esempio sopra, in combinazione con un tipo di regola multimediale su come dereferenziare il contenuto dell'elemento risultato è ipermedia nello stesso modo in cui:

<result>/foo/1234</result> 

è con una regola per anteporre base URI http. Così è l'esempio qui sotto dove il fatto che la stringa http è dereferenziabile può essere lasciato implicito.

<result>http://myserver.com/foo/1234</result> 

Tuttavia, mentre sono tutte ipermediale e soddisfare tale vincolo, direi contro creare i propri nuove regole di produzione ipermediale e tag, se possibile, a soli riutilizzo di quelli esistenti. Il primo esempio rende meno ovvio all'utente che questo elemento rappresenta una risorsa con collegamento ipertestuale rispetto all'ultimo esempio.

Answer 4

Suggerirei piuttosto che il codice a mano questi collegamenti ipertestuali, utilizzare uno strumento che crea quei collegamenti ipertestuali per voi. La programmazione orientata all'interazione è un buon metodo per creare queste interazioni (collegamenti ipertestuali). Si prega di seguire questo link questa tecnologia ha funzionato per noi http://www.masterkube.com/hateoas_technology.html

Answer 5

In un minimo (anche se non fate niente altro), si dovrebbe mettere l'URL in un attributo invece del contenuto dell'elemento XLink:

<resulturi xlink:href="http://resultserver/results/1234.xml"/> 

XML i processori sono in grado di analizzarli e seguirli come URI in modo nativo. Come regola generale, un testo che non è traducibile o che non potrebbe mai avere sotto-elementi dovrebbe essere in un attributo per far rispettare tali restrizioni.

Ma oltre a questo, fai ciò che altri hanno suggerito e definisci il tuo tipo di media in modo che il significato possa essere compreso dai clienti.