I principi SOLID applicabili all'API: s

Question

I principi SOLID applicabili all'API: s

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

0

Ho creato un'API (web) con un paio di endpoint, che a loro volta hanno molte operazioni CRUD. Il codice stesso è conforme ai principi SOLID. Ora ho un consumer per quell'API che afferma che se usano la mia API infrangerà i principi SOLID alla loro fine perché la mia API fornisce più funzionalità di quelle che richiedono.

Ha senso per quanto riguarda Principio di segregazione dell'interfaccia .

ISP splits interfaces that are very large into smaller and more specific ones so that clients will only have to know about the methods that are of interest to them.

Diciamo che ho un'API che gestisce i clienti. Ha metodi per creare, leggere, aggiornare e rimuovere i clienti. Ma il consumatore non ha bisogno di aggiornare o rimuovere. Dovrei quindi creare una nuova API che ometta i metodi di aggiornamento e rimozione? E quindi solo fornire metodi che sono di interesse per il consumatore?

Ad esempio, se intendi utilizzare l'API Facebook Graph molto probabilmente fornirà più funzionalità di quelle necessarie. Significa che infrangi i principi SOLIDI quando lo usi?

api-design solid

posta smoksnes 22.09.2016 - 10:29

fonte

2 risposte

2

La maggior parte delle interfacce che hanno più utenti (oltre "Usa" e "Test") avranno alcuni metodi non usati da ogni utente dell'interfaccia, ciò non significa che quei metodi dovrebbero essere eliminati, perché la fine estrema di ciò sarebbe essere un'interfaccia per utente e nessun metodo nell'intersezione.

Concettualmente Aggiorna (Valore - > Valore) copre Crea (Nil - > Valore) ed Elimina (Valore - > Nil), quindi potresti argomentare per un'API readonly e un'API di lettura / scrittura.

Dì loro di scrivere un involucro sottile che espone semplicemente CR e nasconde UD se vogliono essere pignoli.

risposta data 22.09.2016 - 11:04

fonte

Leggi altre domande sui tag api-design solid

È meglio avere molte eccezioni specificate o alcuni generali generati con una descrizione specifica? Devo includere una spiegazione sul framework utilizzato in una documentazione del programmatore?

score 5 · Accepted Answer

L'utilizzo di un'API non dovrebbe portare a infrangere alcun principio a meno che l'API non sia gravemente danneggiata. Se alcune API hanno più funzionalità del necessario in alcune applicazioni, il che è abbastanza normale, è sempre possibile nascondere l'API dietro un'interfaccia personalizzata limitata nel consumatore. Problema risolto, se mai ce n'è stato uno.

Tuttavia, se la tua API ha molti consumatori e questi consumatori potrebbero avere interessi in conflitto, è probabilmente consigliabile prendere in considerazione la possibilità di suddividere l'interfaccia in modo che le interfacce vengano condivise solo tra i consumatori con preoccupazioni simili. È meglio evitare situazioni in cui un cambiamento dell'API richiesto da alcuni consumatori porta a cambiamenti indesiderati in dozzine di consumatori. Questa è la logica dietro ISP.

I consumatori che non hanno bisogno di nient'altro che leggere e trovare operazioni avranno in genere interessi diversi rispetto ai consumatori che devono modificare i dati. Avere un consumatore che crea e legge solo entità non è probabilmente lo scenario più comune.