15 küsimust, mida peaksite nende platvormi kohta küsima enne platvormi valimist

Üks hea sõber ja mentor kirjutasid mulle küsimuse ja ma tahaksin selle postituse jaoks kasutada oma vastuseid. Tema küsimused olid veidi rohkem suunatud ühele valdkonnale (e-post), nii et olen üldistanud oma vastused kõigile API-dele. Ta küsis, milliseid küsimusi peaks ettevõte enne valiku tegemist müüjalt küsima oma API kohta.

Miks vajate API-sid?

An rakenduse programmeerimisliides (API) on liides, mille arvutisüsteem, raamatukogu või rakendus pakub, et võimaldada teistel arvutiprogrammidel teenusetaotlusi esitada ja / või võimaldada nende vahel andmeid vahetada.

Wikipedia

Samamoodi kui sisestate URL-i ja saate vastuse veebisaidile, on API meetod, kus teie süsteemid saavad andmete vahel sünkroonimiseks taotleda ja saada vastuse. Kuna ettevõtted soovivad end digitaalselt ümber kujundada, on API-de kaudu ülesannete automatiseerimine suurepärane viis organisatsiooni sisese efektiivsuse suurendamiseks ja inimlike eksimuste vähendamiseks.

API-d on automatiseerimisel kesksel kohal, eriti turundusrakendustes. Üks väljakutseid, kui ostate suurepärase müüjaga kõikehõlmavat API on see, et arendusressursid ja -kulud on tavaliselt järelmõtted. Turundusmeeskond või ühine turukorraldus võib juhtida rakenduse ostmist ja mõnikord ei saa arendustiim palju sisendit.

Platvormi integreerimisvõimaluste uurimine API kaudu nõuab rohkem kui lihtne küsimus, Kas on olemas API? Ja järgmine küsimus:

Mis tüüpi API-sid on olemas?

API-tehnoloogiaid on palju erinevat tüüpi, millest igaühel on oma spetsiifilised funktsioonid ja kasutusjuhud. Teie rakenduse jaoks sobivaim API-tehnoloogia tüüp sõltub teie konkreetsetest vajadustest ja nõuetest. Siin on 6 levinumat API-tehnoloogia tüüpi.

1. REST API-d - REST API-d on teatud tüüpi veebi-API, mis kasutab andmete toomiseks ja töötlemiseks HTTP-meetodeid (nt GET, POST, PUT ja DELETE). REST API-d on loodud olema kerged ja paindlikud ning neid kasutatakse sageli veebi- ja mobiilirakenduste loomiseks.
2. SEEBI API-d - SOAP (Simple Object Access Protocol) API-d on teatud tüüpi veebi API, mis kasutab andmete kodeerimiseks ja HTTP kaudu edastamiseks XML-i (Extensible Markup Language). SOAP API-d on rohkem standardiseeritud ja struktureeritumad kui REST API-d ning neid kasutatakse sageli ettevõtte keskkondades, kus turvalisus ja töökindlus on olulised.
3. GraphQL API-d – GraphQL on API-de päringukeel, mis võimaldab arendajatel taotleda API-lt konkreetseid andmeid, selle asemel et saada fikseeritud andmekomplekti. GraphQL API-d on paindlikud ja võimaldavad arendajatel taotleda ainult neid andmeid, mida nad vajavad, mis võib parandada jõudlust ja vähendada andmete raiskamist.
4. Veebikonksud – Veebihaagid on teatud tüüpi API-tehnoloogia, mis võimaldab serveril saata kliendile andmeid reaalajas, selle asemel, et klient peaks serverilt andmeid küsima. Veebihaake kasutatakse sageli rakendustevahelise reaalajas suhtluse võimaldamiseks ja teatud sündmuste korral toimingute käivitamiseks.
5. Pilve API-d – Pilve API-d võimaldavad arendajatel juurdepääsu pilvandmetöötlusteenustele, nagu salvestusruum, andmebaasid ja analüütika, ning nendega suhelda. Need API-d võivad aidata arendajatel rakendusi tõhusamalt ja tõhusamalt luua ja juurutada.
6. Riistvara API-d – Riistvara API-d võimaldavad arendajatel pääseda juurde riistvaraseadmetele, nagu andurid, kaamerad ja printerid, ja neid juhtida. Neid API-sid saab kasutada rakenduste loomiseks, mis suhtlevad füüsiliste seadmetega ja juhivad neid.

Kui logite sisse rakendusega, millel on halvasti toetatud või dokumenteeritud API, ajate oma arendustiimi hulluks ja teie integreerumine tuleb tõenäoliselt lühike või ebaõnnestub täielikult. Leidke õige müüja ja teie integreerimine toimib ning teie arendajad aitavad teid hea meelega!

Uurimisküsimused nende API võimaluste kohta:

1. Funktsiooni lünk - Tehke kindlaks, millised nende kasutajaliidese funktsioonid on rakenduse programmeerimisliidese kaudu saadaval. Mis funktsioone API-l on, mida UI-l pole ja vastupidi?
2. Skaala - Küsige, kui palju neile helistatakse API iga päev. Kas neil on spetsiaalne serverite kogum? Kogus on uskumatult oluline, kuna soovite kindlaks teha, kas API on ettevõtte strateegia järelmõju või tegelikult osa sellest.
3. dokumentatsioon - küsige API dokumentatsiooni. See peaks olema kindel, täpsustades kõik API-s saadaval olevad funktsioonid ja muutujad.
4. kogukond - Küsige, kas neil on veebiarendajate kogukond koodi ja ideede jagamiseks teiste arendajatega saadaval. Arendajate kogukonnad on teie arendus- ja integreerimispüüdluste kiireks ja tõhusaks käivitamiseks võtmetähtsusega. Selle asemel, et kasutada ettevõttes API-tüüpi meest, kasutate ka kõiki nende kliente, kellel on juba olnud lahenduse integreerimisel katseid ja vigu.
5. API tüübid – Kasutatava API tüübi tundmine võib integreerimine olla üsna lihtne. Kui te pole API kasutamise funktsioonide ja nõuetega tuttav, on aga vastupidi.
6. keeled - Küsige, milliste platvormide ja rakendustega nad on edukalt integreerunud, ja küsige kontakte, et saaksite nende klientide käest teada saada, kui keeruline oli integreeruda ja kui hästi API töötab.
7. Piirangud - Küsige, milliseid piiranguid on müüjal kõnede arv tunnis, päevas, nädalas jne. Kui te pole skaalautuva teenuseosutaja juures, piirab klient teie kasvu.
8. Näidised - Kas nad pakuvad koodinäidete kogu lihtsaks alustamiseks? Paljud ettevõtted avaldavad SDK-d (tarkvaraarenduskomplektid) erinevatele keeltele ja raamistikele, mis kiirendab teie integreerimise ajaskaalat.
9. liivakast - Kas nad pakuvad tootmiseks mitteseotud lõpp-punkti või liivakasti keskkonda, et saaksite oma koodi testida?
10. Ressursid - Küsige, kas neil on oma ettevõttes spetsiaalseid integratsiooniressursse. Kas neil on integreerimiseks saadaval sisemine konsultatsioonigrupp? Kui jah, siis visake mõni tund lepingusse!
11. TURVALISUS - Kuidas nad API abil autentivad? Kas see on kasutaja mandaat, võtmed või muu metoodika? Kas nad saavad päringuid piirata IP-aadressi järgi?
12. Töö kestvus - Küsige, mis neil on API tööaeg ja veamäär on ning kui nende hooldustunnid on. Samuti on olulised strateegiad nende ümber töötamiseks. Kas neil on sisemisi protsesse, mida uuesti proovida API kõned juhul, kui kirje pole mõne muu protsessi tõttu saadaval? Kas see on midagi, mille nad on oma lahenduses välja töötanud?
13. SLA - Kas neil on a Service Level Agreement kus uptimes peaks olema 99.9% ülespoole?
14. Tegevuskava - Milliseid tulevasi funktsioone nad oma API-sse lisavad ja millised on eeldatavad tarnegraafikud?
15. Integrations - Milliseid produtseeritud integratsioone nad on välja töötanud või mida on arendanud kolmandad osapooled? Mõnikord võivad ettevõtted loobuda funktsioonide sisemisest arengust, kui juba on olemas teine ​​tootlik integratsioon ja seda toetatakse.

Nende küsimuste võti seisneb selles, et integratsioon "abiellub" teid platvormiga. Sa ei taha ju kellegagi abielluda, kui pole temast võimalikult palju teada saanud? See juhtub just siis, kui inimesed ostavad platvormi, teadmata selle integreerimisvõimalustest.

Lisaks API-le peaksite proovima ka välja selgitada, millised muud integratsiooniressursid neil võivad olla: vöötkoodid, kaardistamine, andmete puhastamise teenused, RSS, veebivormid, vidinad, ametlikud partnerite integratsioonid, skriptimismootorid, SFTP tilgad jne.