Una o più API RESTful per grandi aziende?

Question

Una o più API RESTful per grandi aziende?

#1 da (4 voti)
#2 da (4 voti)
#3 da (3 voti)

3

Lavoro per una grande azienda che ha diverse API non RESTful. Ho il compito di creare un'applicazione web per interagire con queste API. Ogni API gestisce e fornisce processi e dati aziendali molto diversi.

Mi piacerebbe creare interfacce RESTful (a) che facciano fronte alle API in modo da renderle riutilizzabili da altre applicazioni web future. Quindi, mi piacerebbe che JavaScript interagisse con le interfacce RESTful.

Devo creare una API RESTful (un sottodominio) per la mia intera azienda

http://api.mycompany.com
    /business_process_1/resource/
    /business_process_2/resource
    /business_process_3/resource

e renderlo frontale ai processi e ai dati aziendali molto diversi? Oppure, dovrei creare più API (più sottodomini)?

http://business-process-1.mycompany.com
http://business-process-2.mycompany.com
http://business-process-3.mycompany.com

api-design api rest

posta Chad Johnson 24.07.2012 - 01:31

fonte

3 risposte

Leggi altre domande sui tag api-design api rest

Differenza tra i fagioli Javabean e Java Low Coupling: Principio della singola responsabilità rispetto alla coesione

score 4 · Answer 1

La domanda chiave qui è se la tua azienda è soggetta a vendere / disinvestire una delle sue divisioni o prodotti?

Se la risposta è sì, probabilmente vorrai avere un URL per marca o per prodotto. Se la tua azienda è una società "prodotto unico", un unico URL è la strada da percorrere.

score 4 · Answer 2

REST non è l'URI

L'implementazione più comune di REST consiste nella combinazione di URI, HATEOAS e verbi HTTP. Quindi suggerirei che concentrarsi sulla creazione di una struttura URI è un po 'prematuro.

Fondamentalmente, dovresti progettare la tua API in modo che sia individuabile da un cliente che comprende il contenuto del payload. Ad esempio, assicurandoti che il tuo payload contenga link con rel e microformats significa che i tuoi clienti diventano meno dipendenti dagli URI e più dipendenti da ciò che è contenuto nel payload per guidarli.

In questo modo, puoi indirizzare i tuoi clienti alla versione più appropriata delle loro API tramite collegamenti con la semantica che sono stati programmati per comprendere, in genere attraverso l'uso appropriato dei codici di stato HTTP.

Per un uso generale, leggero, il formato del payload considera Hypertext Application Language (HAL) .

E la mia domanda?

Detto questo, più sottodomini con JavaScript portano a problemi di dominio incrociato che (sebbene mitigati usando approccio document.domain ) portano alla complessità del client. Da quel punto di vista, dovresti considerare un singolo punto di partenza e costruire da lì.

score 3 · Answer 3

Probabilmente correrei con un singolo URL per far fronte ai servizi web per questioni di semplicità su alcuni livelli. Con moderni proxy e trucchi per il bilanciamento del carico, un singolo URL non vincolerà le tue mani nella misura in cui le opzioni infrastrutturali sono disponibili.

Manca la parte più cruciale della tua strategia URL - versione la tua API. Questa è l'unica cosa che ti mette nei guai nella misura in cui i tuoi URL sono preoccupati. Tutto il resto è risolvibile con un nuovo endpoint.

Per quanto riguarda l'implementazione, è molto probabile che tu voglia optare per singoli endpoint piuttosto che qualcosa di monolitico - ti ringrazierai a lungo termine. Ti permetterà di uscire dalla porta più velocemente in quasi tutti i casi per l'avvio.