API multiple o una API con un parametro "chooser"?

5

Supponiamo che tu abbia un servizio web, che aggiunge la logica di business su un'origine dati. A quanto assomigliano tutte le API di questo servizio, dato un insieme di vincoli, forniscimi gli elementi dall'origine dati che soddisfano questi vincoli. Puoi dire che ottieni una "vista" dell'origine dati dall'API.

Ora, nel corso del tempo ti viene chiesto di restituire diversi tipi di visualizzazioni sull'origine dati. Hai la possibilità di aggiungere nuove API per ogni vista "sufficientemente distinta", o di cambiare marcia e fornire un'API getFooDataView (), che accetta un parametro che specifica il tipo di visualizzazione che desideri. Hai diverse pressioni concorrenti per decidere quale strada percorrere:

  • Il grande cliente esistente del tuo servizio preferirebbe essere pigro e non dover codificare le nuove API quando sono necessarie nuove viste sui dati.
  • Tuttavia, alcuni dei parametri della tua richiesta (vincoli) hanno senso solo per alcune visualizzazioni, e non per gli altri - dovresti rendere più flessibile il tuo contratto API dicendo "bene se vuoi XYZ view, settando il" foo " parametro non avrà alcun effetto ", con lo sfortunato effetto collaterale che non è possibile rendere" foo "un parametro obbligatorio anche se è così per alcune delle viste.
  • Sta diventando sempre più il caso che i nuovi clienti vogliono sfruttare il tuo servizio. Non puoi decidere quale sarebbe più confusionario per loro - dovendo scegliere tra API diverse, ma più definite, e una API in cui devono sapere quale combinazione di parametri dà loro realmente ciò che vogliono.

Per distillare questo, quando si disegna la linea che qualcosa dovrebbe essere la sua API in contrapposizione a una variazione di un'API esistente? Diverse persone con cui lavorare hanno opinioni diverse su ciò che rende semanticamente distinte due richieste client, quindi può essere difficile ottenere un consenso su questo argomento. Desiderate inoltre assicurarvi che il vostro servizio non sia proibitivo per i futuri clienti. Quali sono alcune buone pratiche che fanno questo tipo di scelta?

    
posta RuslanD 20.11.2013 - 22:56
fonte

1 risposta

3

Personalmente preferirei API più piccole e più strette. Non penso che ne consegue che avere un'API one-size-fits-all rende qualcosa di più semplice da utilizzare, anzi forse l'inverso dato che è necessario trovare la giusta combinazione di "ju-ju" tipicamente non tipizzato per ottenere quello che vuoi mentre un'API più stretta può essere resa più auto-esplicativa. Stai solo nascondendo la complessità invece di renderla esplicita.

È anche probabile che la tua API diventi sempre più complessa in quanto avvolge sempre più funzionalità, mentre le API più restrittive restano focalizzate e snelle.

Questo sa di Principio di segregazione dell'interfaccia su una scala più grande.

Ci sono sempre altri modi (come una buona guida) per aiutare i clienti a scegliere l'approccio giusto.

    
risposta data 20.11.2013 - 23:40
fonte