Endpoint API specializzati o più chiamate a risorse generiche?

Question

Endpoint API specializzati o più chiamate a risorse generiche?

#1 da (4 voti)

5

Questo problema si è verificato durante la progettazione dell'API per un'applicazione Web SPA, che comunica con il server tramite AJAX.

In una pagina l'utente, che sta creando un elenco di persone da invitare a un evento, ha la possibilità di aggiungere persone che sono state invitate a eventi precedenti. Immagina un menu a discesa contenente i nomi degli eventi precedenti. Quando viene selezionato un evento, un multiselect viene compilato con tutti gli invitati a quell'evento precedente. L'utente può selezionare da queste persone e premere "Aggiungi", che le aggiunge all'elenco di invitati per l'evento corrente.

Se immagini la struttura dei dati dietro il menu a discesa / multiselect descritto, potrebbe essere qualcosa del genere:

previousEventGuests [
  { 
    eventName: 'Company Christmas Dinner',
    guests: ['Joe Smith', 'Andy Jones', ...]
  },  
  ...
]

La domanda sorge spontanea: come vengono scaricate queste informazioni dall'API?

Vedo due approcci di alto livello:

Scrivi uno specifico endpoint dell'API per rispondere a questa specifica esigenza:
```
/previousEventsAttendees
```

che restituisce esattamente i dati sopra.

Effettua chiamate multiple a endpoint di risorse generiche

/events                    (foreach event_id returned, call....)
  /event/:event_id         (to get each event's name)
  /event/:event_id/guests  (forach list of user_ids returned, call...)
    /user/:id              (to actually get each users name)

I pro di 1. sono che devi solo effettuare una singola chiamata AJAX e che hai un codice di elaborazione dati molto inferiore sul client. Il principale problema che vedo è che hai creato un endpoint strettamente connesso a questa particolare visualizzazione all'interno di questa particolare applicazione.

I pro di 2. sono che non stiamo utilizzando nient'altro che endpoint di risorse generiche, che potrebbero essere riutilizzati da molte viste e applicazioni differenti. I contro sono che dobbiamo fare molte chiamate AJAX e mettere insieme tutte le risposte per ottenere il formato che vogliamo.

Le mie domande sono: 1. Quali fattori dovrei prendere in considerazione quando si prendono questi tipi di decisioni? Il fatto che questa API sia un'API aziendale interna (e quasi certo che rimanga tale), piuttosto che uno pubblico, influenza la mia decisione? C'è un modo per ottenere il meglio da entrambi i mondi? 2. So che questo è un problema generale connesso ai principi di REST e con molte soluzioni (credo che Falcor sia un approccio più recente alla risoluzione di almeno un problema simile). Dovrei guardare ad altri approcci?

design api-design api rest

posta Jonah 30.06.2016 - 02:26

fonte

1 risposta

Leggi altre domande sui tag design api-design api rest

Come gestire le operazioni con array di grandi dimensioni in Javascript? Perché la parola chiave statica è stata utilizzata qui?

score 4 · Accepted Answer

Perché non entrambi?

Cioè, sì, ci sono dei compromessi da considerare, ma se il costo marginale di implementare una seconda opzione è piccolo, puoi offrire ai tuoi clienti la possibilità di selezionare la rappresentazione che preferiscono, in modo che possano scegliere le proprie compensazioni (ovviamente, c'è una penalità di complessità da pagare offrendo una scelta, piuttosto che risolvere "il" problema per i clienti).

The major con I see is that you've built an endpoint tightly coupled to this particular view within this particular application.

Non proprio la lingua giusta, da una prospettiva REST. Non è il endpoint che è accoppiato all'applicazione, ma il tipo di media della rappresentazione.

Ovviamente, preoccuparsi dei tipi di media tende a cadere nel dimenticatoio quando stiamo implementando sia il client che il server, e i loro cicli di rilascio sono accoppiati.

The pros of 2. are that we are using nothing but generic resource endpoints, which could be re-used by many different views and applications.

Questo pensiero è incompleto - puoi non solo riutilizzare gli endpoint, ma puoi riutilizzare le rappresentazioni da sé ... cioè: il caching. Se il client è in grado di estrarre i dati necessari dalla propria cache, non è necessario effettuare il round trip. In caso contrario, una cache intermedia potrebbe già avere una copia dei dati, riducendo il round trip. Il "server" con cui sta parlando il client potrebbe essere una farm di cache di fronte all'app, mantenendo basso il carico di lavoro mentre è in grado di scalare.

In REST, vuoi assicurarti che i tuoi disegni sfruttino l'interfaccia uniforme.

Quindi una delle cose a cui dovresti pensare è la durata della cache delle tue risorse; quanto tempo sono valide le rappresentazioni? Altre viste e applicazioni saranno in grado di trarne vantaggio?

Should the fact that this API is an internal company API (and almost certain to remain so), rather than a public facing one, influence my decision?

È probabile che limiti il volume di traffico che dovrai supportare. Inoltre, se i clienti si troveranno in una posizione centrale, allora anche il tempo di andata e ritorno diminuirà.