A cosa dovrei pensare quando si rende pubblica un'API interna? [chiuso]

Devi assolutamente creare nuovi endpoint API per l'accesso di terze parti, in quanto alcuni dei requisiti non funzionali sono destinati a essere diversi. Ad esempio,

• Le API esterne tendono ad avere versioni di manutenzione meno frequenti
• Le interfacce API esterne non possono essere riviste senza l'approvazione congiunta
• I requisiti di sicurezza potrebbero essere diversi
• I requisiti di prestazioni e disponibilità potrebbero essere diversi
• La tua capacità di cogliere l'impatto di modifiche anche minime al codice viene notevolmente ridotta, in quanto parte del codice che utilizza la logica è all'esterno della tua azienda
• Potresti trovare nuovi problemi di compatibilità
• La terza parte potrebbe chiederti di apportare alcune modifiche solo per loro

Inoltre,

• Devi scrivere le note di rilascio ora (ugh!)

È meglio fare la pausa ora. Se inizialmente non immaginavi che la tua API fosse in mano a un estraneo, probabilmente non è pensata per essere così.

Cogli l'occasione per riordinare le tue interfacce e i DTO in modo che abbiano più probabilità di avere un senso per qualcuno che non li ha mai visti. Probabilmente sarai tu quello che dovrà rispondere alle domande più tardi, quindi potresti anche risparmiare un po 'di lavoro e provare a rendere l'API il più intuitiva possibile.

Idealmente, non dovresti fare la domanda in primo luogo. Esistono pochi motivi per cui un'API non viene resa pubblica dall'inizio, mentre ci sono importanti vantaggi, in termini di sicurezza, per rendere pubblica l'API non appena viene rilasciata la prima versione stabile.

Ora che ti trovi in una situazione in cui devi porre la domanda, ci sono alcuni elementi che possono aiutarti a decidere:

• L'API utilizza gli standard? Un'API REST basata su swagger è molto più user-friendly di un'API che utilizza un protocollo interno non documentato. Se sei nel secondo caso, dimentica di utilizzare l'API così com'è. Crea un intermediario che esporterà le funzionalità tramite REST e / o SOAP e le indicizzerà sull'API interna.

• Se l'API cambia continuamente, difficilmente può essere aperta al pubblico. Un'interfaccia API pubblica non può cambiare una volta al giorno o alla settimana: dovrebbe essere relativamente stabile. Una volta che l'endpoint pubblico inizia a essere utilizzato, è necessario fornire supporto per un tempo sufficiente. Ciò significa che devi implementare la strategia di versioning e devi pensarci due volte prima di spingere una nuova versione in produzione. Gli errori sottostanti potrebbero essere corretti, ma gli errori a livello di interfaccia ti perseguiteranno per mesi o anni.

• L'API era scritta pensando alla sicurezza? Spesso gli sviluppatori si affidano al fatto che, dal momento che qualcosa è interno, non deve essere sicuro (come se nessun dipendente desiderasse danneggiare l'azienda un giorno). Prima di esporre tale API al pubblico, è necessario ricontrollare ogni chiamata, ogni parametro, per vedere come si comporta l'API [mis].

• Se hai reinventato la ruota durante l'implementazione del meccanismo di autenticazione, dimentica di aprire l'API al pubblico. Probabilmente hai sbagliato la parte di autenticazione e la scoprirai nel modo più duro.

• Come sono gestiti gli attacchi DOS e DDOS? Se sotto attacco DDOS, puoi comunque accedere ad altre risorse, come i log di sistema?