rende Discoverability REST e HATEOAS implica che è possibile modificare gli URI?

Question

Sto cercando di chiarire un concetto correlato alla rilevabilità REST - che è se o meno soddisfare il vincolo HATEOAS per un servizio RESTful significa che ora gli URI possono cambiare, perché sono rilevabili e non documentati.

Questo sembra non seguire il concetto di Cool URIs - il fatto che gli URI non cambiano, mai. È anche alquanto in disaccordo con il modello del web stesso (che REST dovrebbe essenzialmente adattarsi perfettamente) - il fatto che gli URL siano bookmarkable e non cambino mai, e il fatto che una volta che ne impari uno, puoi andare direttamente ad esso e lo fai non è necessario passare attraverso la radice e scoprirlo ogni volta.

Qualsiasi feedback su questo è apprezzato.

Answer 1

Per Cool URI, no, non dovresti cambiarli, mai. Sono i punti di ingresso nel tuo sistema. Tuttavia, dovresti avere pochissimi di quelli se vuoi avere la capacità di evolvere il resto della struttura URI del tuo sistema in futuro.

Per tutti gli URI non fredde, hanno può infatti cambiare nel tempo. Recentemente ho scritto uno blog post su questo argomento perché trovo che la capacità di REST di permettermi di evolvere il mio sistema nel tempo sia incredibilmente utile.

Assicurarsi che la documentazione dell'API specifichi il fatto che solo i pochi URI di raffreddamento nel sistema devono essere hard-coded dai client e qualsiasi altro URI deve essere rilevato in fase di esecuzione tramite hypermedia traversal. Pensa a loro come a un indirizzo puntatore C: a nessuno importa il valore esadecimale di una variabile puntatore, ma sono sicuri che vorrebbe che indicasse un posto valido in memoria. Lo stesso vale per gli URI non raffinati: la loro struttura non ha importanza, ma il fatto che siano stati recuperati in fase di runtime tramite conversazioni con il server li rende validi.

Answer 2

Deve esserci documentazione. MediaTypes e Link Relations sono un punto di accoppiamento e sia il client che il server devono capirlo. Ecco perché HTML, ATOM e RSS hanno degli standard.

In termini di funzionamento runtime posso vedere che non ho documentazione. Non ho bisogno di sapere che cosa ha Yahoo sulla sua home page perché posso scoprirlo. Allo stesso modo, un cliente del mio servizio non ha bisogno di sapere di una nuova funzionalità che rilascio. Possono trovare il collegamento esiste e quindi utilizzare la relazione di collegamento per vedere cosa fa.

Così la documentazione è di circa le norme e protocolli che devono essere utilizzati, ma non come l'applicazione funzionerà stesso