Funzionalità di strutturazione dell’API
Non ho molta esperienza quando si tratta di creare API. Ho fatto una buona parte del lavoro quando si tratta di integrare WordPress con API di terze parti, ma ho dedicato pochissimo tempo alla creazione di un sistema che ha la sua API con cui altri sistemi possono interagire.
Per quanto riguarda quest’ultimo, in realtà sono nel mezzo di farlo (e sto imparando molto). L’essenza del progetto è che esiste un’app iOS che interagisce con WordPress tramite l’API REST in modo bidirezionale.
Non vedo l’ora di condividere di più su di esso, ma ho bisogno di farlo quando il progetto sarà più avanti.
Ma quando si tratta di lavorare con API di terze parti e quindi di creare componenti di un progetto WordPress che interagiscono con esse, due delle cose che trovo costantemente utili sono:
- utilizzando una libreria adeguata ,
- diagrammare il sistema,
- separando la funzionalità in parti.
E gli ultimi due punti sopra sono ciò che sto cercando di coprire in questo post.
Funzionalità di strutturazione dell’API
Nessun codice è coinvolto in questo post, ma forse sarà una guida su come andare avanti nel tuo lavoro con la strutturazione delle funzionalità API o facendo qualcosa di simile da solo.
Biblioteche di terze parti
Lo dico solo perché penso che sia prezioso riutilizzare soluzioni provate e vere che sono state testate (e quindi utilizzate) su tutta la linea in una varietà di progetti.
Guzzle è la mia libreria preferita. Sì, WordPress ha funzioni integrate per comunicare con altri URL, ma c’è di più che puoi fare con Guzzle (soprattutto per quanto riguarda i componenti della richiesta) che con WordPress.
Certo, questa è la mia opinione, ma mi piace lavorarci. E la documentazione è solida.
Diagramma del sistema
Quando lavori con l’integrazione con API di terze parti abbastanza a lungo, devi abituarti al processo di impostazione del funzionamento del sistema. Di solito, va qualcosa del genere:
- creare un client API per connettersi all’API,
- impostare le funzioni necessarie per effettuare le richieste di cui hai bisogno,
- analizzare la risposta,
- restituirlo all’oggetto o alla funzione originale che ha invocato la richiesta.
Questa è un po’ una semplificazione eccessiva (dopotutto, la creazione del client API può essere un compito in sé e per sé), ma i punti rimangono tutti gli stessi (e potrebbero non creare una brutta serie 🤔).
Ad ogni modo, soprattutto, diagrammare il sistema non fa mai male. Questo è qualcosa che faccio ancora perché mi aiuta, in un certo senso, ad articolare ciò che sto costruendo e vedere se ci sono lacune nel flusso di controllo attraverso l’applicazione.
Ecco perché, se non altro motivo, questo è importante: articolare ciò che hai intenzione di fare ti aiuta a capire cosa stai facendo e spesso espone lacune nel tuo pensiero che dai per scontate.
Quindi, quando si tratta di progettare un sistema, non dare per scontato di aver capito tutto.
Separare la funzionalità
Se leggi questo blog da molto tempo, allora sai che sono un fan di seguire tutte le idee di sviluppo della "separazione delle preoccupazioni".
Questo è vero per molteplici ragioni, la più piccola delle quali non è:
- essere in grado di testare un client API in isolamento,
- mantenendo indipendente il codice per la comunicazione con il front-end e il back-end.
Quando si dispone di una classe dedicata all’esecuzione della logica aziendale sui valori, è possibile scaricare gran parte della gestione degli errori nella classe intermedia.
Ciò significa che la classe principale responsabile della maggior parte della logica aziendale dovrebbe avere esattamente ciò di cui ha bisogno per svolgere il proprio lavoro. Ciò non significa che non dovrebbe essere presente un controllo degli errori (divisione per zero o qualcosa del genere, sai?), ma significa che i dati possono essere controllati prima ancora che arrivino alla classe principale tramite la classe intermedia.
E non solo può controllare eventuali informazioni mancanti, ma può anche segnalare tali errori al front-end.
Tre punti da ricordare
Se stai creando un sistema basato su Ajax in WordPress, il punto di tutto questo è triplice:
- diagramma il sistema che stai creando,
- creare una classe interstitial per gestire le informazioni mancanti e segnalare gli errori,
- inviare le informazioni complete alla classe aziendale principale solo dopo che tutte le informazioni sono state verificate.
Dopo averlo fatto, l’obiettivo sarebbe che la classe aziendale principale restituisca i valori richiesti senza errori poiché saranno stati catturati prima ancora di raggiungerli.