API HATEOAS e sviluppo front-end

1

Stiamo sviluppando uno strumento da zero basato su un backend Spring e sul frontend di VueJs. Sto principalmente lavorando al back-end e sono venuto a conoscenza del principio HATEOAS di sviluppare API REST e l'ho adottato. Confesserò che uno dei motivi per adottarlo è stata l'implementazione fuori dagli schemi fornita da Spring.

Tuttavia, il nostro sviluppatore di frontend è scettico sull'utilizzo delle API REST di HATEOAS per lo sviluppo del frontend. Le API sono direttamente collegate al database, quindi se usa questa API solo deve effettuare più chiamate per ottenere dati relazionali. Per es. se vuole ottenere i dettagli del libro insieme all'ID della biblioteca in cui si trova, deve effettuare 2 chiamate, una per ottenere i dettagli del libro e un'altra chiamata a un collegamento associato alla risposta del libro che gli fornisce i dettagli della libreria. Vuole invece una singola chiamata API che avrebbe l'id della libreria come una proprietà aggiuntiva con i dettagli del libro.

Ora ovviamente il front-end non utilizza un'unica API, ci sono molte API e ho dedicato più tempo allo sviluppo di API personalizzate rispetto a qualsiasi logica di back-end.

Ora ho 2 menti su quale strada è corretta:

  1. Il front-end dovrebbe effettuare più chiamate se necessario, il che creerebbe sicuramente ritardi, per conformarsi agli standard HATEOAS
  2. Il front-end dovrebbe chiamare solo API personalizzate e le API dovrebbero essere create in modo che i dati possano essere recuperati con meno chiamate possibili.

Quale dovrebbe essere seguito?

    
posta Sayak Mukhopadhyay 12.07.2018 - 17:15
fonte

3 risposte

3

I vantaggi di HATEOAS (Hypermedia) sono reali sia per le API interne che esterne. Tuttavia, spesso mancano gli strumenti per trarre vantaggio da questi vantaggi.

Iniziamo con il "problema" di fare richieste multiple al server. Ci sono diverse soluzioni Prima di tutto, se il front-end deve costantemente fare più richieste per ottenere ciò di cui ha bisogno, si può avere un problema di modellazione dei dati. La tua API non dovrebbe semplicemente mappare 1: 1 al tuo database. Concentrati sulla modellazione dei flussi di dati attraverso il sistema, piuttosto che sulla modellazione dei dati.

Tuttavia, anche se devi effettuare più chiamate, esistono diverse soluzioni a tua disposizione. Il tuo strumento più importante è la cache HTTP. In teoria, dovresti essere in grado di recuperare una risorsa una volta e quindi mantenere quella copia locale della risorsa sincronizzata con il server. Se apporti una modifica alla tua copia locale, informa il server della modifica con una richiesta PUT e continua a utilizzare la tua copia locale. Checkout questo blog per una buona spiegazione di questo approccio, o ottenere una copia del libro, "REST in pratica" (ancora il miglior libro su REST che ho letto tutti).

Se le risorse cambiano molto frequentemente sul server o vengono modificate frequentemente da altri utenti API, questo approccio potrebbe non essere molto utile. Fortunatamente, ci sono altre opzioni. Alcuni formati ipermediali come Siren e HAL consente alle risposte di restituire non solo la risorsa richiesta, ma anche altre risorse che prevede che si desideri anche richiedere richieste di follow-up. Ti incoraggio a controllare quei tipi di media.

Tuttavia, la funzionalità push del server HTTP / 2.0 rende obsoleta questa funzionalità. Questo fondamentalmente risolve lo stesso problema, ma a livello di protocollo. Non conosco bene questa funzione, quindi non cercherò di spiegarlo ulteriormente. Il problema con questo, ovviamente, è il supporto lato server scarso per questa funzione. Speriamo che i nostri framework web si aggiorneranno presto.

Ora parliamo del problema più grande, la mancanza di strumenti di front-end. La sfida principale sul lato client è che il front-end deve capire come utilizzare le risposte abilitate da Hypermedia dal server. Questo può essere molto lavoro e non è qualcosa che gli ingegneri front-end vogliono avere con se stessi, e non dovrebbero farlo. Ciò è particolarmente vero quando iniziamo a parlare di alcuni dei formati Hypermedia più complicati e più potenti come JSON Hyper Schema . Con gli strumenti giusti, gli ingegneri front-end non dovrebbero nemmeno sapere quali collegamenti vengono seguiti per ottenere i dati richiesti.

So che non ci sono state piccole ondate di mano in questa risposta, ma è un argomento piuttosto ampio e complicato. Ti incoraggio a seguire alcuni di questi link per saperne di più. Sono fiducioso che un giorno gli strumenti saranno abbastanza buoni da non dover più pensare a questa roba. Dopo tutto, quanto è necessario sapere su HTTP, HTML, un URI per poter utilizzare un sito come questo. Fondamentalmente zero, e dovrebbe essere lo stesso per chiunque usi la tua API.

Un'ultima cosa che ti lascerò è che REST non è necessariamente la scelta giusta per tutti i casi d'uso ed è giusto non usare hypermedia se non si adatta alle tue esigenze. Oggigiorno, la maggior parte delle persone prende questa decisione con una buona dose di ignoranza, ma è una domanda valida da porre e hai ragione a chiederlo. Assicurati di conoscere i compromessi e la buona fortuna per identificare le buone fonti di informazione dal cattivo.

    
risposta data 13.07.2018 - 07:42
fonte
2

REST è progettato per facilitare la stabilità e la riusabilità dell'API su un orizzonte temporale molto lungo quando si hanno più client al di fuori del proprio controllo. Sembra che il tuo progetto abbia un singolo client API sotto il tuo controllo. Stando così le cose, è molto ragionevole adattare il set di funzionalità alle esigenze e ai desideri di quel singolo cliente. Assicurati solo che le parti interessate comprendano che stai creando un prodotto per un singolo cliente, non qualcosa che può essere dato al mondo esterno.

    
risposta data 12.07.2018 - 17:25
fonte
0

Sia onesto, HATEOAS non vale la pena di essere implementato.

Tuttavia, sembra che il tuo problema non riguardi realmente HATEOAS. Riguarda ciò che è incluso nel modello. Anche se il chiamante api conosce già tutti gli endpoint, dovrà ancora effettuare due chiamate, GetBook e GetLibraryWithBookIn, a meno che non si inventi un nuovo ViewModel BookWithLibraryInfo e si aggiungano metodi API per recuperarlo.

Vorrei sconsigliare questo dato che ogni utente dell'API vorrà diversi ViewModels, finirai con centinaia di essi. Attenersi ai Modelli che si associano alle tabelle DB è una buona politica.

Esiste un modo alternativo per risolvere il problema, ovvero creare una seconda API come parte del back-end del sito Web.

Ciò renderebbe più chiamate alle API, combinare i dati in base alle esigenze del sito Web in modelli di visualizzazione e restituirli al front-end in una singola chiamata.

In questo modo il front-end può avere i modelli di visualizzazione specifici di cui ha bisogno e l'API può rimanere generica e utilizzabile dalle applicazioni principali.

    
risposta data 12.07.2018 - 17:44
fonte

Leggi altre domande sui tag