Endpoint dell'API Web singola per tutte le entità, buone o cattive?

Question

Endpoint dell'API Web singola per tutte le entità, buone o cattive?

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

1

Situazione

Al momento stiamo sviluppando una grande applicazione web (Web API 2) - diverse entità e quindi richiedono diversi endpoint per ciascuno. Ma all'improvviso, hanno cambiato l'approccio di "un endpoint adatto a tutti", qualcosa del tipo:

/api/data?entity=entity_name

Quindi il solito controller per GET, POST, PUT, DELETE. Abbiamo qualcosa di simile:

public class DataController : ApiController
{
    public HttpResponseMessage Get(string entity)
    {
        Type entityType = Type.GetType(entity);
        var query = HelperClass.GenerateGenericGetMethod<entityType>("GetAll").ToList();
        return Response(OK, query);
    }
}

Come puoi vedere, abbiamo creato un helper per generare un metodo generico per Get, GetById e le stesse vecchie vecchie query, applicheremo un altro set di helper per: rimuovere le proprietà per tornare al client e altre azioni personalizzate .

Domanda

Questo causerà un sovraccarico al server? Andrà bene se aumenteremo tutto in futuro? (E sono sicuro che lo faremo) Come aggiungere l'autenticazione token, i ruoli utente, l'accesso mobile e altro ancora. Vorrei alcuni approfondimenti.

Grazie!

EDIT: Sono abbastanza nuovo per lo sviluppo web e mi piacerebbe sentire alcuni suggerimenti su quale approccio si adatta meglio alla nostra situazione.

api-design api asp.net web

posta dandansoysauce 24.09.2016 - 17:17

fonte

2 risposte

Leggi altre domande sui tag api-design api asp.net web

Miglior algoritmo per multi-thread di questa applicazione? Che cosa significava James Gosling quando ha detto che C # è Java senza affidabilità, produttività e sicurezza? [chiuso]

score 4 · Answer 1

Sinceramente dubito che Web API 2 abbia qualche problema con un singolo endpoint. Potrebbero esserci delle considerazioni di cui non sono a conoscenza, ma non sembra essere il fattore limitante.

Il vero problema di questo approccio è ciò che fa per la comprensibilità e la manutenibilità del codice, oltre a rendere più facile il tracciamento e il debug.

Per il primo problema è che /api/data?entity=widget è meno espressivo di, diciamo, /api/widget .

Questi ultimi formano meno rumore e comunicano più chiaramente l'intento.

Un altro fattore è la crescita delle tue API. Se inizi con un singolo recupero per ognuno, il singolo punto di ingresso potrebbe non sembrare male. Ma diciamo che inizi a dover fare un paio di domande: widget per ID e widget per nome. La stringa dell'URL inizia ad apparire come /api/data?entity=widget&id=123 o /api/data?entity=widget&name=Frobnitz . Poco a poco, il tuo metodo Get inizia ad accumulare sempre più controlli per capire quale query intendi, specialmente se aggiungiamo un'entità Foo che può essere anche cercata per ID.

In generale, sarebbe probabilmente utile leggere un po 'sui servizi web REST e applicare alcuni dei principi generali (alcune delle cose più pesanti sono probabilmente eccessive per la tua situazione).

score 1 · Answer 2

Oltre al commento OP

Yes, that was my point I gave them, but they needed concrete reasons why it will fail in the future

Nessuno conosce il futuro. Se il modello e i requisiti non cambiano nei prossimi 100 anni, la soluzione proposta sarà di successo.

Chiunque tutti noi sappiamo che i cambiamenti avvengono. I requisiti cambiano, il business cambia e (dalla mia esperienza) questi così generici e astratti collidono con flessibilità alla fine.

Ad esempio, tornando al tuo scenario, a un certo punto , tutto ciò che non rientra nella stringa di query sarà obbligato a viaggiare attraverso il corpo e alcuni GETS diventeranno POST / PUT e la grammatica della tua API sarà un po 'contorta e difficile da leggere.

Will it be okay if we scale it all up in the future? (And I'm sure we will).

È difficile prevedere in che modo l'approccio avrà un impatto sulla scalabilità. Ci sono diversi modi per scalare e tutti dipendono da diversi bisogni e scenari. Quindi, come ho letto qui molte volte iniziare poco e poi ridimensionare in base ai bisogni reali.

Tuttavia, possiamo dire che tecnicamente l'approccio presenta alcune limitazioni come quella che ho indicato in precedenza.

Like, add token authentication, user roles, mobile access and more. Would like some insights.

Questo tipo di funzionalità può essere implementato (e spesso lo sono) utilizzando le intestazioni della richiesta e della risposta. L'approccio esposto potrebbe non avere alcun impatto.

Oltre alla risposta @Michael.

Per utilizzare alcuni principi RESTful dell'API si ottengono alcuni vantaggi:

API (sintatticamente) sarà più intuitivo
Sarà più "compatibile con gli sviluppatori *. In questi giorni gli sviluppatori sono abituati a questo tipo di sintassi e progettazione, quindi è più facile per loro implementare i clienti.
Il modo di scalare è prevedibile (perché la sua scalabilità è stata dimostrata molte volte dai progetti che li hanno applicati)
I possibili inconvenienti di questo approccio sono già stati rilevati e la comunità ha offerto diverse soluzioni a ciascuno di essi. Quindi non c'è bisogno di improvvisare soluzioni che risultino sconosciute.
Questo è quello che nessuno fa (o raramente). L'approccio potrebbe essere il risultato della "geniale idea" di qualcuno che potrebbe essere e solo potrebbe essere, sarà presente durante tutta la vita dell'API e il suo mantenimento sarà possibile a basso costo. Ma come uso per dire Fai cose come se non avessi intenzione di essere lì per mantenerli . Chiunque venga dopo di te dovrebbe essere in grado di comprendere la soluzione riducendo al minimo la curva di apprendimento.

Finalmente torna al commento OP

but they needed concrete reasons why it will fail in the future

Sarebbe positivo per te e per chiunque altro coinvolto nello sviluppo, per conoscere "loro" ragioni per implementare un singolo endpoint. Quali sono i loro argomenti? Il contro e il per. Quindi sarai in grado di rispondere con argomenti che potrebbero comprendere.