Un'API dovrebbe essere a conoscenza di una versione client?
L'idea di questo è davvero contraria, ma sembra che venga spinto nel mio attuale progetto.
Mi sbaglio? Posso avere qualche motivo a favore o contro di ciò che posso presentare o capire perché potrebbe essere buono.
L'API è una RESTful API.
Un'API dovrebbe essere il più coerente possibile. Effettuare la stessa chiamata all'API dovrebbe sempre fare la stessa cosa. Rispondere in modo diverso in base alla versione del client sarebbe inaspettato e confuso. Potrebbe portare a errori impercettibili, in quanto qualcuno che aggiorna un cliente otterrebbe risultati diversi e non sapeva perché.
Naturalmente, puoi creare funzioni che forniscono diversi livelli di dati disponibili per soddisfare esigenze diverse. Ma dovrebbero essere offerti a tutti e gli utenti dell'API possono decidere quale livello vogliono.
Quasi senza eccezione, no . I metodi rappresentano i comportamenti. I comportamenti generalmente non dovrebbero cambiare a seconda di chi sia il consumatore. Ad esempio, quando entri in un ristorante, ti aspetti di ricevere un trattamento diverso a causa del tuo genere o del colore della tua pelle? Ovviamente no. Il contratto implicito che ogni ristorante fa con il mondo è: "Vieni nel mio ristorante, ti do un menu da cui scegliere le cose, e mangi la cosa che hai selezionato." Il fatto che io possa non sapere quale dei cibi è è irrilevante . Questo è il problema IL MIO , non il problema del ristorante. Il ristorante non può diventare un parrucchiere, semplicemente perché è quello che io, come cliente, voglio o pretendo. Questo è uno dei modi in cui finiamo con l'antipattern Oggetto di Dio. Definire chiaramente le responsabilità dei clienti e dei produttori è estremamente importante in OOAD.
Quindi, questa è la regola. Ci sono alcune eccezioni al caso d'angolo, ma al momento non vengono in mente.
Il problema che è possibile eseguire senza l'idea di supportare la versione client è che diventa molto difficile modificare le rappresentazioni dei dati richieste e inviate dall'API. Le modifiche alla rappresentazione possono costringere le applicazioni client a cambiare e lasciarle in uno stato rotto fino a quando non lo fanno.
Non includere uno schema di versione client ha senso se l'API è ragionevolmente statico e i suoi metodi non sono soggetti a modifiche, solo aggiunte.
Idealmente non dovresti scegliere tra non essere in grado di modificare il contratto di servizio e rompere i client.
Il codice base sottostante non deve necessariamente preoccuparsi della versione del client se si dispone di punti di distribuzione specifici della versione gestiti tramite uno schema di percorso url (ad esempio link , link , ecc.). Dovresti comunque gestire più copie del codice con questo schema.
Sebbene io sia d'accordo con @ dan1111 sul fatto che un server non ha attività diverse a seconda della versione del client, posso vedere un caso in cui aggiungi una funzione a una delle API e:
In questo caso, penso che sia una strategia fattibile per aggiungere la tua funzionalità in modo difensivo, aggiungendo un codice ad hoc per supportare il vecchio client in modo da non romperlo, fino al completamento del roll-out.
Dopo quel periodo, puoi rimuovere in sicurezza il codice ad hoc, in modo da non finire con un codice frammentato e ingombrato.
Leggi altre domande sui tag api-design api rest