In REST: WADL o non IDL, è il seguente approccio giusto?

Question

Questa domanda è un po 'lunga, si prega di sopportare con me. In REST, penso che non dovremmo aver bisogno di WADL o di qualsiasi IDL. Ma piuttosto qualcosa che implicitamente coprirebbe il suo concetto. Il modo in cui penso è quando noi (umani) navighiamo sul Web, quando andiamo su un sito web per la prima volta, non sappiamo quali servizi fornisce. È scoprire quelli nella home page html (o una pagina sitemap in una sezione di aiuto) o forse solo il menu principale sulla home page. Se si fa un'analogia, la home page o la mappa del sito per noi umani è ciò che WSDL è per WS- * o quale WADL potrebbe essere per un servizio REST. Solo che è proprio come qualsiasi altro contenuto HTML. Penso che in REST il seguente è un buon modo per fare le cose, rispettando il paradigma HATEOS. Avere una risorsa di livello superiore (o predefinita) che elenca i collegamenti alle altre risorse. Per un esempio biblioteca, dicono RestLibrary.com/ potrebbe essere qualcosa di simile:

<root xmlns:lib="http://librarystandards.com/libraryml"> 
<resource class="lib:book"> 
    <link type="application/vnd.libraryml+xml" template="mylib.com/book/{isbn}" /> 
    <link type="application/vnd.libraryml+xml" rel="add" href="mylib.com/book" method="POST" /> 
    <link type="application/vnd.libraryml+xml" rel="update" template="mylib.com/book/{isbn}" method="PUT" /> 
</resource> 
<resource class="lib:bookList"> 
    <link template="mylib.com/book?keywords={keywords}" type="application/vnd.openlibrary+xml" rel="search" /> 
</resource> 
</root> 

noti che si assume che il tipo di supporto "application/vnd.libraryml + xml" è una definizione standard o (può essere solo vocabolario proprietario) denominato libraryml. Inoltre, il client dovrebbe essere in grado di comprendere questa risorsa "homepage" (elementi root, risorse e link). Questa è la parte che potrebbe essere utilizzata al posto di WADL: un vocabolario astratto che dovrebbe essere comprensibile da qualsiasi cliente. Ad esempio, potresti utilizzare uno standard esistente come Atom. Ma l'idea principale è di avere un vocabolario astratto comprensibile da qualsiasi cliente. Perché allora non WADL? bene wadl è solo per la scoperta del servizio. L'idea qui è di avere un vocabolario astratto leggero che potrebbe servire come base per l'ipermedia. Un vocabolario di "radice". Come nel gufo abbiamo il gufo: cosa ... ecc. Ora se il client conosce lo standard "libraryml" può seguire i collegamenti alle cose che comprende (dopo aver analizzato le proprietà del tipo di supporto e xmlns). In caso contrario, non lo farà.

Quando non riesco a capire come gestire qualcosa nell'architettura REST, tendo a vedere come noi Umani lo facciamo nel Web. Nel Web, abbiamo il linguaggio generico che è HTML che consente ai costruttori di siti di fornire qualsiasi contenuto specifico, indipendentemente dal suo significato per il cliente (l'utente), i browser comprendono l'HTML ma non il "significato" del suo contenuto. È l'utente che comprende il contenuto (specifico del dominio). Se vado a dire QuantumPhysics.org, il mio browser può rendere la home page (dopotutto è solo html) e posso leggere la home page. Se capisco quantum allora posso continuare a navigare. Se io non ho appena uscire (a meno che non voglio imparare la hardway :))

• Nell'esempio RetsLibrary.com l'applicazione cliente è proprio come me + mio browser
• su QuantumPhysics.org . il tipo di supporto "application/vnd.libraryml + xml" è fisica quantistica (conoscenza).
• http è http in entrambi gli esempi.
• Ora HTML di QuantumPhysics.org è in RestLibrary.com è XML + quel piccolo piccolo vocabolario astratto (root risorse e di collegamento, che si potrebbe sostituirlo con qualcosa come Atom).

Quindi questo approccio ha qualche valore? non abbiamo bisogno di un minuscolo iper-vocabolario di root in modo che possiamo avere successo con hypermedia e il concetto di "URI iniziale"?

modificare Sì perché non RDF come il vocabolario di root!

Answer 1

Sì, vedo sicuramente la necessità di questo tipo di tipo di supporto.

Stavamo parlando di questo tipo esatto di cosa sul freenode canale IRC REST l'altro giorno dopo Mike Kelly ha suggerito la necessità di una "Hypermedia Lingua dell'applicazione" application/hal + xml

Vedi http://restafari.blogspot.com/2010/06/please-accept-applicationhalxml.html per un esempio.

RDF sembra eccessivo per questo tipo di cose, ma sarei felice di essere smentito. Trovo RDF più focalizzato su Linked Data di HATEOAS.