La reperibilità in HATEOAS richiede che le informazioni siano leggibili dal computer o semplicemente leggibili dall'uomo?

Question

La reperibilità in HATEOAS richiede che le informazioni siano leggibili dal computer o semplicemente leggibili dall'uomo?

#1 da (2 voti)

5

Sto cercando di capire i concetti di HATEOAS (Hypermedia As The Engine Of Application State) in REST. I seguenti sono stati molto utili:

Che cosa fa HATEOAS offri la possibilità di scoprire e disaccoppiare oltre alla possibilità di modificare la struttura dell'URL più o meno liberamente?

Le API REST devono essere guidate da un ipertesto (da Roy Fielding se stesso)

Da loro capisco che HATEOAS non si limita a fornire link per dire al cliente quali sono le prossime azioni valide, ma anche fornire informazioni sui metodi validi che possono essere applicati a una risorsa e il formato dei dati passato in entrambe le direzioni tra il client e il server.

È il formato dei dati con cui ho problemi. Roy Fielding menziona la definizione di nuovi tipi di media per descrivere i formati dei dati. Se devono essere creati nuovi tipi di media per ogni API creata da qualcuno, verranno definiti centinaia di migliaia di tipi di supporti monouso.

Per ovviare a questo problema, qualcuno ha suggerito di utilizzare il tipo di supporto HAL ( Hypertext Application Language ) per le API RESTful. HAL include il concetto di CURIE, prefissi per nomi di relazioni che si espandono in URL che puntano alla documentazione.

Ad esempio,

"_links": {
  "curies": [
    {
      "name": "doc",
      "href": "http://haltalk.herokuapp.com/docs/{rel}",
      "templated": true
    }
  ],

  "doc:latest-posts": {
    "href": "/posts/latest"
  }
}

Qui il nome della relazione è doc:latest-posts dove doc è un CURIE che si espande a http://haltalk.herokuapp.com/docs/ , e http://haltalk.herokuapp.com/docs/latest-posts punterà alla documentazione sulla risorsa degli ultimi post (si noti che l'URL alla risorsa degli ultimi post di per sé, al contrario della documentazione su di esso, è /posts/latest )

Questo sembra un buon modo per gli sviluppatori sul lato client di conoscere ogni risorsa fornita dall'API. Ma avere un collegamento automatico con la documentazione leggibile dall'uomo soddisfa i requisiti di rilevabilità di HATEOAS? O le informazioni che descrivono i formati di dati richiesti per ogni risorsa devono essere leggibili dal computer (ad esempio un tipo di supporto personalizzato per l'API)?

rest hateoas

posta Simon Tewsi 17.01.2016 - 04:43

fonte

1 risposta

Leggi altre domande sui tag rest hateoas

Tutte le dipendenze transitive del software GPL devono essere compatibili con GPL? Plan, Build, Run philosophy philosophy

score 2 · Accepted Answer

Come hai sottolineato, Roy Fielding ha scritto un articolo interessante sul suo blog. E questo paragrafo riassume piuttosto bene "Come HATEOAS":

A REST API should spend almost all of its descriptive effort in defining the media type(s) used for representing resources and driving application state, or in defining extended relation names and/or hypertext-enabled mark-up for existing standard media types. Any effort spent describing what methods to use on what URIs of interest should be entirely defined within the scope of the processing rules for a media type (and, in most cases, already defined by existing media types). [Failure here implies that out-of-band information is driving interaction instead of hypertext.]

Quindi, sì HATEOAS si affida a fornire collegamenti ai client per guidarli sull'applicazione. Un esempio tipico è, come parte di un'applicazione bancaria, un conto bancario in cui si dispone di un link per prelevare e un altro link per effettuare un deposito. Se il saldo è negativo, il link di prelievo scomparirà. Questo è HATEOAS: fornisci i link per aiutare il cliente.

Ma aspetta un minuto. Nel paragrafo citato, Fielding parla di descriptive effort , media type e out-of-band information ... interessante :-)! Infatti, HATEOAS non si limita a fornire link, perché non è sufficiente che un cliente abbia solo link privi di significato. In che modo il client dovrebbe conoscere i verbi da richiamare quando si segue un link? (GET / POST / PUT?) ... Come si suppone che il cliente conosca i dati da passare come parametro quando si segue un collegamento? Se il cliente non conosce queste informazioni, è semplice: il tuo cliente si affida a out-of-band information (e questo è baaaaaad!)

Ecco la parte interessante: come può il cliente ottenere questa informazione? Risposta: tramite self-descriptive messaggio e media-type usato! È così che rendi HATEOAS: tu fully (non solo fornendo link!) Guida il client con link e messaggi auto-descrittivi.

A seconda dell'applicazione, potrebbe essere necessario definire il proprio tipo di supporto che descriverà accuratamente il messaggio. Alcuni altri esistono, sono chiamati "formato ipermediale". HAL è uno di loro ma ha alcune limitazioni. Un confronto obsoleto può essere trovato qui: link

Personalmente, ti suggerisco di dare un'occhiata a Hydra, che probabilmente sarebbe uno standard W3C e ha molte caratteristiche. Ad esempio, è possibile definire quali operazioni sono possibili su un collegamento (= quali verbi utilizzare, quali dati passare come parametro, se richiesto o meno, ecc ...). Alcune interessanti presentazioni possono essere trovate qui: link

Per concludere: direi che HATEOAS è correlato alla leggibilità della macchina. Autodescrivendo il messaggio, dai la possibilità a qualsiasi macchina di capire la tua API. Perché la leggibilità umana potrebbe coinvolgere la conoscenza fuori banda e questo in genere non è RESTful (né compatibile con HATEOAS).