Strukturera API-funktionalitet
Jag har inte så mycket erfarenhet när det gäller att skapa API:er. Jag har gjort en hel del arbete när det kommer till att integrera WordPress med tredjeparts API:er, men jag har lagt ner väldigt lite tid på att skapa ett system som har sitt API som andra system kan interagera med.
När det gäller det senare är jag faktiskt mitt uppe i det (och jag lär mig mycket). Kontentan av projektet är att det finns en iOS-app som interagerar med WordPress via REST API på ett dubbelriktat sätt.
Jag är sugen på att dela med mig av mer om det, men jag måste göra det när projektet är längre fram.
Men när det gäller att arbeta med tredje parts API:er och sedan bygga komponenter i ett WordPress-projekt som interagerar med dem, är två av de saker jag konsekvent tycker är användbara:
- använda ett lämpligt bibliotek ,
- diagram över systemet,
- dela upp funktionaliteten i delar.
Och de två sista punkterna ovan är vad jag vill täcka i det här inlägget.
Strukturera API-funktionalitet
Ingen kod är inblandad i det här inlägget, men det kanske är en guide till hur du kan gå vidare i ditt arbete med att strukturera API-funktionalitet eller göra något liknande på egen hand.
Tredjepartsbibliotek
Jag nämner detta bara för att jag tror att det är värdefullt att återanvända beprövade och sanna lösningar som har testats (och därmed använts) över hela linjen i en mängd olika projekt.
Guzzle är mitt favoritbibliotek. Ja, WordPress har inbyggda funktioner för att kommunicera med andra webbadresser, men det finns mer du kan göra med Guzzle (särskilt när det gäller komponenter i begäran) än med WordPress.
Visst, detta är min åsikt, men jag tycker om att arbeta med det. Och dokumentationen är solid.
Diagrammering av systemet
När du arbetar med att integrera med tredje parts API:er tillräckligt länge, ska du vänja dig vid processen att ställa in hur systemet fungerar. Vanligtvis går det ungefär så här:
- skapa en API-klient för att ansluta till API:t,
- ställ in de funktioner som krävs för att göra de förfrågningar du behöver,
- analysera svaret,
- returnera det till det ursprungliga objektet eller funktionen som anropade begäran.
Detta är lite av en överförenkling (att skapa API-klienten kan trots allt vara en uppgift i och för sig), men alla poäng är desamma (och kanske inte blir en dålig serie 🤔).
Hur som helst, framför allt skadar det aldrig att diagramma systemet. Det här är något jag fortfarande gör eftersom det hjälper mig på sätt och vis att formulera vad det är jag bygger och se om det finns luckor i flödet av kontroll genom applikationen.
Här är varför, om ingen annan anledning, detta är viktigt: Att formulera vad du ska göra hjälper dig att förstå vad du gör och avslöjar ofta luckor i ditt tänkande som du tar för givet.
Så när det gäller att lägga upp ett system, anta inte att du har fattat allt.
Separera funktionaliteten
Om du har läst den här bloggen hur länge som helst, då vet du att jag är ett fan av att följa hela utvecklingsidéerna för "separation of concerns".
Detta är sant av flera skäl, varav de minsta inte är:
- kunna enhetstesta en API-klient isolerat,
- hålla koden för kommunikation med front-end och back-end oberoende.
När du har en klass dedikerad till att köra affärslogik på värdena, kan du överföra mycket av felhanteringen till mellanklassen.
Detta innebär att kärnklassen som ansvarar för majoriteten av affärslogiken bör ha exakt vad den behöver för att utföra sitt arbete. Detta betyder inte att det inte finns någon felkontroll som borde vara på plats (division med noll eller något, du vet?), men det betyder att data kan kontrolleras innan den ens når kärnklassen via mellanklassen.
Och det kan inte bara kontrollera om det saknas information, utan det kan också rapportera dessa fel tillbaka till front-end.
Tre punkter att komma ihåg
Om du skapar ett Ajax-beroende system i WordPress är poängen med allt detta trefaldig:
- diagram systemet du skapar,
- skapa en mellanliggande klass för att hantera eventuell saknad information och rapportera tillbaka felen,
- skicka endast den fullständiga informationen till kärnverksamheten efter att all information har verifierats.
När du har gjort det, skulle målet vara att få kärnverksamheten att returnera de begärda värdena utan fel eftersom de kommer att ha fångats innan de ens nådde det.