Progettazione API REST: come suddividere l'oggetto API per rendere l'API più scalabile e robusta

Question

Progettazione API REST: come suddividere l'oggetto API per rendere l'API più scalabile e robusta

#1 da (2 voti)
#2 da (1 voti)

3

Disponiamo di siti Web di e-commerce per telefoni cellulari. Stiamo costruendo API riposante sui telefoni POST, PUT, DELETE, UPDATE.

Ogni cellulare avrà caratteristiche di base come: prezzo, produttore, anno di produzione, colore, sconto.

Oltre a questo, anche la maggior parte dei cellulari avrà immagini.

Inoltre, alcuni di questi hanno garanzia del produttore. Diciamo il 50% di loro.

E pochi dei cellulari avranno a disposizione opzioni finanziarie, come ad esempio il legame con alcune banche per facilitare il prestito per queste. Quasi l'80% avrà questa funzione.

Stavamo decidendo due approcci per progettare api per questo:

Approccio 1. Tutti questi nello stesso oggetto JSON. Solo una API come:

{   
    "basicInfo": {
      "price": "",
      "mfgYear": "",
      "manufacturer": ""
    ...
  }, 
    "images":{...},  
    "warranty":{...},    
    "finance":{...}    
   }

Approccio 2. Tutti questi oggetti JSON sono separati. Ad esempio:

Primo Api per "basicInfo".
Seconda Api per "immagini".
Terza API per "garanzia".
Quarta Api per "finanza" Potrei capire alcuni pro e contro di ciascuno:

APPROACH1: Pro: Riceviamo tutte le informazioni del magazzino insieme sul server. Ciò significa meno hit API, meno carico sul server. Inoltre, in futuro, se implementeremo qualche elaborazione di coda per salvare queste informazioni di magazzino in un database, non ci saranno mai casi di immagine / garanzia / finanza prima che lo stock venga inserito nel database poiché abbiamo tutte le informazioni insieme qui. Quindi, prima inseriremo il magazzino nel database e quindi inseriremo il record in altre tabelle che avranno una relazione di chiave esterna. Contro: questa API / risorsa ha più responsabilità. Diventerebbe sempre più grande e potrebbero esserci troppi campi in questa API in futuro. Mi sembra anche una violazione del principio di responsabilità unica.

APPROACH2: Pro: Sembra un po 'più pulito e organizzato. Sembra che ogni API abbia la propria responsabilità definita. Sembra scalabile per me. Se viene apportata una modifica in un'API, è meno probabile che influenzi le altre API. Contro: numero maggiore di hit API sul server. Sono pubblicate maggiori probabilità di risorse dipendenti di azioni che vengono registrate prima dello stock. Ad esempio, possiamo rimuovere le immagini prima che le immagini siano inserite.

Approach3. Fornire entrambe le opzioni. Esempio che consente di inviare altre informazioni con informazioni di base e creare API separate per queste risorse.

Qual è l'approccio migliore, ossia più riposante, scalabile e con prestazioni migliori?

api-design rest

posta maverick 21.02.2017 - 05:54

fonte

2 risposte

Leggi altre domande sui tag api-design rest

Come si restringono classi specifiche per una proprietà? Modello di bandiera auto-modificante e implementazione standard

score 2 · Answer 1

Uno dei principi di un'interfaccia REST è che ai consumatori non dovrebbe essere richiesto di avere conoscenze intrinseche dove trovare le informazioni correlate a una risorsa che hanno appena recuperato.
Ciò significa che se ho appena recuperato una risorsa del telefono dal link , non avrei bisogno di sapere se le immagini si trovano a link o link o da qualche parte il resto.

Per evitare di mettere tale conoscenza nei consumatori dell'interfaccia, viene utilizzata una combinazione del tuo approccio 1 e 2: la rappresentazione di base della risorsa contiene collegamenti alle posizioni in cui informazioni aggiuntive (come immagini, opzioni finanziarie, ecc.) possono essere recuperato In questo modo, la struttura JSON non diventa troppo gonfia (specialmente con immagini che non sono particolarmente adatte per il trasferimento in JSON) e il client non deve indovinare dove recuperare le informazioni aggiuntive se e quando ne hanno bisogno. / p>

score 1 · Answer 2

Se vuoi che l'API sia RESTful, deve essere stateless per definizione.

L'approccio 2 non è apolidi, nel senso che per ottenere tutte le informazioni devi emettere diverse richieste che devono essere ricomposte in seguito, cioè dipendere l'una dall'altra.

Per ottenere un'interfaccia pulita potresti dare un'occhiata a jsonAPI.org , che definisce un specifica per scrivere API usando json.