Înțelegerea platformelor bazate pe API: un ghid pentru managerii de produs

A construi un produs digital astăzi înseamnă a integra multitudinea de diverse sisteme de back-office cu punctele de contact și dispozitivele clienților. Costul angajării unei echipe de software pentru a le conecta într-o singură soluție de lucru ar putea crește vertiginos.

Acesta este motivul pentru care managerii moderni de produs, atunci când aleg furnizorii, pun adesea capabilitățile de integrare în primul rând, ceea ce se poate reduce la alegerea sistemelor care expun API. Ce este API-ul și cum să îl testați fără a implica echipa dvs. de tehnologie? Citește mai departe.

Îmbrățișați datele: de ce avem nevoie de API-uri

Datele clienților schimbă modul în care funcționează afacerea. Dacă sunt colectate și mutate în mod corespunzător, ele pot ajuta companiile să crească ratele de achiziție și reținere a clienților, ducând în cele din urmă la o explozie a veniturilor.

Dar strângerea datelor este o muncă plictisitoare. De aceea, afacerile au apelat la informatică. În anii 1990, bazele de date care automatizau cele mai consumatoare sarcini de date au devenit masiv populare în cadrul departamentelor de marketing. Acest lucru a dus la o schimbare masivă a modului în care au fost concepute strategiile de marketing - această schimbare a fost numită abordarea bazată pe date .

Bazele de date au avut un dezavantaj major, totuși. Pentru a le face ceva de valoare, o companie trebuia să angajeze ingineri software. Ei au fost eroii care au știut cum să transforme grămezi uriașe de date în perspective de lucru. Ei erau, de asemenea, paznicii care protejează integritatea datelor și, astfel, se asigurau că sistemul era pregătit pentru viitor.

Dar inginerii de software costă mult, iar interfața lor de comunicare a necesitat efort.

Când numărul de canale de colectare a datelor a cuprins mai multe departamente și chiar companii externe, bazele de date și operatorii acestora au devenit un blocaj. Companiile trebuiau să găsească o modalitate automată de accesare a depozitelor de date.

Așa a apărut ideea sistemelor API-first.

Ce este de fapt API-ul fără Tech Lingo

Sistemele API-first, astăzi prescurtate în mod obișnuit ca API ( A pplication P rogrammable Interface), sunt aplicațiile care asigură că alte sisteme își pot accesa datele într-un mod unificat și securizat.

Fără o clasă de informatică, Interfața programabilă pentru aplicații nu prea sună un clopoțel. Să aruncăm o privire la o explicație mai tangibilă.

Una dintre cele mai bune analogii pe care le-am găsit pe web până acum a fost scrisă de Taija:

„Dacă mergi la restaurant ca client, nu ai voie să intri în bucătărie. Trebuie să știi ce este disponibil. Pentru asta ai meniul. După ce te uiți la meniu, faci o comandă unui chelner, care o trece în bucătărie și care apoi va livra ceea ce ai cerut. Chelnerul poate livra doar ceea ce poate oferi bucataria.

Cea mai bună analogie API pe care am văzut-o: ia un restaurant. Meniul este API, comanda ta este apelul API, mâncarea din bucătărie este răspunsul.

— Aarthi 發財 ! (@AarthiD) 19. Decembrie 2013

Cum se leagă asta cu un API? Chelnerul este API-ul. Ești o persoană care cere servicii. Cu alte cuvinte, sunteți client sau consumator API. Meniul este documentația care explică ce poți cere de la API. Bucătăria este, de exemplu, un server; o bază de date care deține doar un anumit tip de date – orice a cumpărat cumpărătorul pentru restaurant ca ingrediente și ce a decis bucătarul că va oferi și ce știu bucătarii să pregătească.”

Deci din nou:

• Bucătărie
  Baza de date, nu au permis clienților să protejeze integritatea datelor.
• Chelner
  API-ul, un intermediar care știe să servească date din baza de date fără a perturba funcționarea acesteia.
• Client
  Un sistem extern care vrea să-și obțină datele
• Meniul
  Formatul de date face referire la sistemele externe pe care trebuie să-l folosească pentru a-și efectua funcționarea.
• Ordin
  Un singur apel API real.

Cu starea actuală a tehnologiei, este încă nevoie de un dezvoltator de software pentru a „face o comandă”. Dar este mult mai rapid (a se citi: mai ieftin) pentru că meniul, ca și McDonald's, este mai mult sau mai puțin standardizat în întreaga lume.

Deci, acum, vom purta pantofii unui dezvoltator de software și vom încerca să apelăm la un API exemplar. Nu vă faceți griji; nu vom merge dincolo de orele școlare de informatică.

Cum obține datele aplicației dvs. de vreme: elemente de bază ale API

Vom afla cum aplicația ta meteo cunoaște temperatura actuală. În acest fel, vom obține elementele de bază despre cum să comunicăm cu sistemele prin internet.

Ce ne trebuie:

• O bază de date meteo
• Un browser
• Un strop de voință

Asta e! Tehnologia actuală face ușoară testarea API-ului fără a fi nevoie de instrumente mari pentru dezvoltatori.

Desigur, asta este diferit atunci când doriți să creați o integrare completă. Când vine vorba de împingere, trebuie să cunoașteți instrumente și limbaje de programare mai avansate, dar pentru testarea/demonstrarea conceptelor, această configurație este suficientă.

Deci, să încercăm să obținem indicele de temperatură curent pentru orașul tău - sau, în limbajul codificatorilor - să invocăm primul apel API. La urma urmei, se rezumă la trimiterea unui text către un server și la primirea unui mesaj în schimb .

Anatomia unei solicitări API

În acest articol, vom folosi API-ul https://openweathermap.org. Vizitați site-ul și încercați să verificați condițiile meteo în mai multe locații. Sper că te simți mai bine decât mine în Katowice astăzi:

După cum probabil ați ghicit, site-ul web apelează API-ul pentru a obține datele. Dezvoltatorii l-au implementat într-un mod în care de fiecare dată când apăsați pe căutare , în culise, aplicația bate ușa API-ului și spune „da-mi temperatura <orașului>”.

Să punem o pălărie de hacker și să vedem apelurile API pe care acest site le apelează cu browserul dvs. Puteți folosi Instrumentele pentru dezvoltatori din browser pentru a vedea ce se întâmplă în culise:

1. În Chrome, accesați Meniu → Mai multe instrumente → Instrumente pentru dezvoltatori;
2. Comutați la fila Rețea;
3. Încercați să verificați temperatura în diferite orașe în widgetul de mai sus;
4. În lista de jos, veți observa linkuri care au fost numite:
   

   

   
   Dacă copiați linkul, puteți vedea că include numele locației și alți câțiva parametri.
   

    https://openweathermap.org/data/2.5/find?callback=jQuery19103887954878001505_1542285819413&q=Katowice&type=like&sort=population&cnt=30&appid=b6907d289e10d714a6e88b30761fae22&_=1542285819418

5. Când inserați linkul în bara de adrese a browserului, ar trebui să vedeți răspunsurile API cu:
   

    jQuery19103887954878001505_1542285819413({"message":"accurate","cod":"200","count":1,"list":[{"id":3096472,"name":"Katowice","coord":{"lat":50.2599,"lon":19.0216},"main":{"temp":281.69,"pressure":1031,"humidity":61,"temp_min":281.15,"temp_max":282.15},"dt":1542285000,"wind":{"speed":3.6,"deg":50},"sys":{"country":"PL"},"rain":null,"snow":null,"clouds":{"all":90},"weather":[{"id":804,"main":"Clouds","description":"overcast clouds","icon":"04d"}]}]})

6. Este puțin haotic, dar dacă scoți conținutul parantezelor și îl rulezi cu un formatator de date, vei vedea o structură care are sens:
   

    { "message":"accurate", "cod":"200", "count":1, "list":[ { "id":3096472, "name":"Katowice", "coord":{ "lat":50.2599, "lon":19.0216 }, "main":{ "temp":281.69, "pressure":1031, "humidity":61, "temp_min":281.15, "temp_max":282.15 }, "dt":1542285000, "wind":{ "speed":3.6, "deg":50 }, "sys":{ "country":"PL" }, "rain":null, "snow":null, "clouds":{ "all":90 },

7. Răspunsul de la API este o structură de date cu informații despre condițiile meteorologice actuale - ar trebui să decriptați cu ușurință majoritatea parametrilor. Acest format de date se numește JSON . Aceasta este o notație importantă, deoarece majoritatea API-urilor moderne o folosesc. Acest teanc de identități și paranteze servește unui singur scop - este mai ușor pentru o aplicație să analizeze un mesaj bine structurat decât un text plasat aleatoriu.

Un cuvânt de explicație despre ceea ce tocmai am făcut aici.

Aplicația web din spatele site-ului web Open Weather Map preia datele din API și le afișează pe site.

De fiecare dată când tastați numele orașului și apăsați pe căutare , site-ul web se conectează la un server cu un link specific care include numele orașului ca parametru.

Aceeași propoziție în jargonul tehnologic: aplicația din spatele site-ului web trimite o solicitare către un punct final API furnizând numele orașului ca argument .

Apoi, API-ul răspunde (trimite un răspuns API ) cu un mesaj text formatat ca JSON .

Pentru a crea o solicitare API, trebuie să adunați adresa acesteia. Da, adresa este o analogie bună. Pentru a expedia ceva trebuie să furnizați curierului:

• Oraș,
• Strada și numărul,
• Uneori, câteva informații suplimentare despre cum să ajungi la birou.

Și, pentru a vă conecta la API, prin analogie, aveți nevoie de:

• https://openweathermap.org/ (link) Orașul sau punctul final rădăcină — un punct de plecare, o adresă de internet a unui server la care doriți să vă conectați, în cazul nostru.
• data/2.5/find (link) Numărul străzii sau calea — determină resursa pe care doriți să o obțineți de la un API.
• ? Callback = JQuery19103887954878001505 1542285819413 & Q = Katowice & Type = Ca & Sort = Populație și CNT = 30 & APPID = B6907D289E10D714A6E88B307619418 (Link) Info Info sau Parametrii de interogare - Lăsați serverul API să știe ce vrem să obținem în special și ce structură și să comandați datele ar trebui să aibă.

Acesta este modul în care sunt proiectate API-urile. Punctul final rădăcină rămâne de obicei același pentru un singur furnizor, apoi trebuie să vă dați seama ce parametri de cale și de interogare sunt disponibili și ce informații au pus echipa de dezvoltare API în spatele lor.

Acum să punem pălăria hackerului puțin mai strâns. În cazul nostru, nu toți parametrii de interogare sunt necesari pentru a obține datele meteo. Încercați să eliminați diferiți parametri după semnul întrebării ( ? ) și verificați cum răspunde API-ul Weather.

De exemplu, puteți începe prin a elimina callback din linkul de solicitare:

 https://openweathermap.org/data/2.5/find?callback=jQuery19103887954878001505_1542285819413&q=Katowice&type=like&sort=population&cnt=30&appid=b6907d289e10d714a6e88b30761fae22&_=1542285819418

Rezultatul:

 https://openweathermap.org/data/2.5/find?q=Katowice&type=like&sort=population&cnt=30&appid=b6907d289e10d714a6e88b30761fae22&_=1542285819418

Dacă te joci cu celelalte, poți vedea că unele dintre ele sunt și ele opționale. De fapt, numai q și appid sunt obligatorii:

 https://openweathermap.org/data/2.5/find?q=Katowice&appid=b6907d289e10d714a6e88b30761fae22

De unde știi ce este obligatoriu și ce este opțional? De unde știi de unde să obții punctul final rădăcină și calea în primul rând?

Documentația API: o citire obligatorie înainte de a începe

Întotdeauna trebuie să verificați mai întâi documentația API pentru a afla cum să vă construiți cererea în mod corect.

În cazul nostru, documentația https://openweathermap.org/current arată punctele finale disponibile. De asemenea, explică toate câmpurile de date de răspuns - astfel încât să puteți găsi ce informații va răspunde API-ul chiar înainte de a trimite o solicitare.

O documentație bună API oferă tutoriale de pornire rapidă despre cum să creați solicitări simple și să treceți la lucruri mai avansate. Din fericire, API-ul Open Weather are unul și îl vom folosi acum.

Crearea unui apel API de la zero

Să rezumam constatările noastre. Am trimis deja o solicitare către API. Ne-am dat seama care este legătura corectă observând ce face OpenWeatherMap în culise. Această abordare se numește inginerie inversă și este adesea dificilă sau deloc posibilă.

Mai mult, de cele mai multe ori, furnizorii de API interzic utilizatorilor să utilizeze excesiv această opțiune. De aceea ar trebui să învățăm cum să „apelăm” API-ul după reguli (sens – documentație).

O modalitate de a face acest lucru este codificarea. Dar, deoarece nu suntem programatori ( încă! ), vom folosi instrumente care ușurează acest lucru. Atât de ușor încât până și dezvoltatorii de software îl au sub centura de instrumente.

După cum am promis, nu vom părăsi browserul. Dar trebuie să instalăm o extensie (numai Chrome) — Postman. Acest plugin simplu transformă browserul într-un conector API.

OK, acum că avem un instrument, să aruncăm o privire în documentație pentru a vedea cum putem obține condițiile meteorologice actuale pentru un anumit nume de oraș https://openweathermap.org/current#name .

Documentele spun că ar trebui să folosim următorul punct final: api.openweathermap.org/data/2.5/weather?q={city name}

Când îl defalcăm, obținem următoarele elemente:

• Punct final rădăcină: api.openweathermap.org
• Calea: data/2.5/weather
• Parametru de interogare: q={city name} (această noțiune înseamnă că ar trebui să înlocuim acoladele cu un nume specific de oraș)

Să-l punem în Postman. Procesul se rezumă la trei pași simpli:

1. Faceți clic pe „Solicitare” în meniul de sus.
   

   

2. Denumiți-vă cererea și furnizați numele catalogului și în secțiunea din partea de jos.

   

3. Lipiți punctul final API pe care doriți să-l apelați, faceți clic pe Trimiteți și ar trebui să vedeți răspunsul API în secțiunea Răspuns:

   

Felicitări! Tocmai ți-ai sunat cu succes bradul... așteaptă o secundă! Să acordăm atenție răspunsului API:

Nu este un JSON plin cu informații despre vreme pe care le-am văzut înainte. Ce înseamnă 401 și cheia API nevalidă? Este greșită documentația noastră?

Autentificare

Nu ai lăsa pe nimeni să acceseze cabinetul tău de cocktail fără permisiunea ta, nu-i așa? În același mod, furnizorii de API-uri doresc să controleze utilizatorii produsului lor pentru a-l proteja de activitățile rău intenționate. Ce este activitatea rău intenționată? De exemplu, trimiterea mai multor solicitări API în același timp, ceea ce va „supraîncălzi” serverul și va cauza timp de nefuncționare pentru alți utilizatori.

Cum poți controla accesul? La fel cum vă păziți băuturile! Prin utilizarea cheilor — chei API .

Dacă vizitați ghidul Cum să începeți din documentația Weather API, veți observa cum vă puteți obține cheia. Înscrie-te acum și verifică-ți căsuța de e-mail.

Deci acum întrebarea este cum să folosești cheia? Este ușor, conform documentelor, doar copiați și lipiți cheia la sfârșitul adresei URL a punctului final (fără acolade).

 api.openweathermap.org/data/2.5/weather?q=Katowice&appid={your API key}

Și faceți clic pe trimite din nou. Iată, acum putem vedea răspunsul API!

Dar există mult mai multe pe care le puteți obține din API folosind Postman. Ești gata să devii un adevărat hacker API?

Parametrii API: obținerea de răspunsuri personalizate

De obicei, punctele finale API au câteva caracteristici utilitare pe care le puteți utiliza pentru a ajusta răspunsul API, de exemplu dacă aveți nevoie de un format de date mai bun sau doriți să obțineți datele într-o anumită ordine. Aceste opțiuni sunt adesea ascunse în spatele unor parametri pe care îi puteți găsi în documentație.

Parametrii de interogare sunt doar un text structurat pe care îl adăugați la adresa punctului final cu următorul model:

1. Un semn de întrebare ( ? ) după cale,
2. Numele unui parametru,
3. Egal ( = ) simbol,
4. Valoarea parametrului,
5. Ampersand ( & ) si altele urmeaza cu punctele 2-4 (in acest fel puteti adauga cati parametri doriti).

Luați ca exemplu prima noastră cerere:

 https://openweathermap.org/data/2.5/find?q=Katowice&appid=b6907d289e10d714a6e88b30761fae22

Notă importantă: ordinea parametrilor de interogare nu contează.

 ?q=Katowice&appid=b6907d289e10d714a6e88b30761fae22

Cele de mai sus sunt identice cu următoarele:

 ?appid=b6907d289e10d714a6e88b30761fae22&q=Katowice

După cum sa menționat, parametrii de interogare sunt descriși în documentele API. Următorul fragment din documentația API-ului meteo vă arată cum să obțineți temperatura în diferite unități (imperiale sau metrice):

Încercați să trimiteți aceste două opțiuni cu Postman pentru a vedea diferența de rezultate. Nu uitați să adăugați cheia dvs. API la sfârșitul adresei punctului final.

Notă : acordați-vă întotdeauna timp pentru a studia documentația și a găsi parametrii care vă pot economisi pe dvs. sau pe echipa de dezvoltare ceva timp serios.

Opțiuni de solicitare API: Cum se trimit date către API

Până acum, am primit informații de la API. Ce se întâmplă dacă dorim să adăugăm sau să modificăm informații în baza de date din spatele API-ului? Metodele de solicitare sunt răspunsul.

Să mai aruncăm o privire la Postman. Este posibil să fi observat o etichetă GET cu majuscule lângă adresa punctului final API. Aceasta reprezintă una dintre cele patru metode de solicitare. GET înseamnă că vrem să obținem ceva de la API (mulțumesc căpitane) și este o opțiune implicită. Care sunt celelalte variante?

Încă confuz? Să trecem la exemple.

API POST: Cum se creează o înregistrare în API

Nu putem crea sau actualiza nimic cu Weather API (pentru că este menit să fie doar pentru citire), așa că trebuie să găsim unul diferit pentru testare.

Să venim cu un exemplu mai orientat spre afaceri. Vom simula următorul scenariu:

Dacă plouă, creați un cupon de reducere „înveselește-te” pentru clienții tăi.

Vom folosi Voucherify, care oferă un API pentru crearea și urmărirea promoțiilor pentru orice sistem de comerț electronic.

Disclaimer : sunt co-fondator al Voucherify. Sunt bucuros să vă răspund la întrebările despre proiectarea și implementarea promoțiilor digitale și despre API-ul nostru, desigur .

Știm deja cum să le obținem din exemplul anterior, așa că să ne concentrăm pe crearea unui voucher:

1. După cum am spus, ar trebui să începem întotdeauna cu documentația.
2. Ghidul de pornire rapidă ne spune să obținem cheia API.
   Notă : În loc să creați un cont, puteți utiliza cheile de testare din ghidul de pornire rapidă - vă vom arăta cum să faceți într-un minut.
3. Acum, să aflăm cum să creăm un cupon de reducere. În Voucherify, acest tip de promovare este reprezentat ca „voucher”.
4. Din documente, veți învăța că pentru a crea voucher, trebuie să apelați o metodă POST la punctul final /vouchers .
5. Creați o nouă cerere în Postman.
6. Schimbați metoda în POST.
   

   

7. Lipiți punctul final Voucherify https://api.voucherify.io/v1/vouchers/ și faceți clic pe Trimitere.
   

   

8. O, nu suntem autorizați să apelăm acest punct final. După cum probabil ați ghicit, trebuie să furnizăm chei API.
   
   Voucherify are un mod ușor diferit de a face acest lucru. În loc să le puneți ca parametri de interogare, ar trebui să le puneți la Antete. Aceasta este o abordare comună, deoarece este mai ușor să implementați și să mențineți cheile în acest fel decât să le adăugați ca parametri de interogare.
   
   Adăugați cheile ca în imagine și faceți clic pe Trimitere. Observați că Voucherify necesită două chei. Iată cele pe care le puteți folosi în scopul acestui tutorial:
   X-App-Id: 8a824b12-0530-4ef4-9479-d9e9b9930176 X-App-Token: 9e322bac-8297-49f7-94c8-07946724bcbc

   

9. Primim un alt mesaj de eroare, de data aceasta spune că sarcina utilă nu poate fi goală.
   

   

   
   Ce dracu este o sarcină utilă? Ca și în cazul GET, vrem să recuperăm unele informații, cu POST trebuie să trimitem ceva și mesajul pe care îl trimitem se numește payload și este de obicei un fișier JSON.
   
   Acum Voucherify API se plânge că nu am furnizat unul, ceea ce înseamnă că nu poate crea un voucher pentru că nu am spus ce fel de voucher ar trebui să creeze. Deci ce acum? Înapoi la documente!
10. Să aflăm de ce fel de informații are nevoie această solicitare pentru a avea succes. Putem vedea o mulțime de opțiuni pe listă.
    

    

    
    Un parametru (tip) este obligatoriu și altul opțional. Să presupunem că va fi o reducere de 20%, disponibilă pentru primii 100 de clienți, care expiră astăzi. Acum trebuie să găsim parametrii responsabili pentru aceste caracteristici de reducere și să îi punem împreună într-un format care să nu fie stabil pentru Voucherify API. După cum puteți vedea în exemplele de mai sus, notația JSON pe care ar trebui să o utilizați arată astfel:

     { "type":"DISCOUNT_VOUCHER", "discount":{ "percent_off":20.0, "type":"PERCENT" }, "expiration_date":"2018-12-03T23:59:59Z", "redemption":{ "quantity":100 }

11. Pentru a configura sarcina utilă în Postman, inserați mesajul JSON în fila Corp. Selectați tipul „raw” și JSON din lista de formate disponibile de încărcare utilă și confirmați cu Trimitere.
    

    

12. Voila! Voucherify a creat cu succes cuponul nostru de reducere de 20% (deoarece lucrăm cu un cont de test, toate codurile generate încep cu prefixul „voucherify.io-”). Echipa de marketing poate acum să partajeze codul clienților, iar Voucherify îl va valida automat ori de câte ori vin în magazinul dvs. pentru a-l valorifica.
    

    

    
    Dar de unde știm că este o cerere reușită? În primul rând, putem vedea că Voucherify ne-a trimis un mesaj care, conform documentelor lor, arată ca un răspuns API corect. În al doilea rând, Poștașul afișează starea 200 OK - ceea ce înseamnă că solicitarea noastră a reușit. De ce 200 și care este starea?

Codurile de stare API și mesajele de eroare

Majoritatea API-urilor cu care veți interacționa vreodată vor fi bazate pe HTTP. HTTP este un protocol care standardizează comunicarea între diverse aplicații client și servere de pe Internet.

Unul dintre elementele cheie ale HTTP sunt codurile de stare. Înțelegând codul de stare, dumneavoastră (sau sistemele pe care le implementați) puteți spune imediat ce s-a întâmplat cu solicitarea dumneavoastră. Sunt șanse să te confrunți cu unul dintre cele mai populare coduri de stare când ai introdus linkul greșit - 404

Dar sunt multe altele și utilizatorii finali de obicei nu le văd. Acestea variază de la 100+ la 500+. În general, numerele respectă următoarele reguli:

• 200+ înseamnă că cererea a reușit;
• 300+ înseamnă că solicitarea este redirecționată către o altă adresă URL;
• 400+ înseamnă că a apărut o eroare care provine din aplicația client;
• 500+ înseamnă că a apărut o eroare care provine de la server.

Dacă ați putea parcurge pașii din nou, ați vedea că Voucherify a răspuns cu 401 Unauthorized când nu am furnizat cheile API. Sau 400 Solicitare greșită când nu a existat nicio sarcină utilă necesară pentru cererea de Creare voucher. În cele din urmă, am primit 200 ca semn al unui apel API de succes.

Dacă sunteți curios despre semnificația codurilor de stare HTTP, nu există un loc mai bun decât HTTP Cats (sau poate acest articol).

rezumat

Cantitatea tot mai mare de date și nevoia de viteză în construirea produselor au împins API-urile să devină lingua franca a echipelor digitale. Pentru a proiecta sisteme bazate pe sisteme API-first, asigurați-vă că înțelegeți ofertele furnizorilor. Acest ghid de testare practică este un bun punct de plecare pentru a face acest lucru. Vă va ajuta să explorați capacitățile API chiar înainte de a le trimite echipei dvs. de profesori, economisind energia acestora - și a dvs., de asemenea.

Lectură suplimentară

• „O introducere în API-urile de comerț electronic pentru non-dezvoltatori”, Scott Brinker
• „Mergeți dincolo de CMS fără cap – Faceți cunoștință cu comerțul fără cap”, Michal Sedzielewski, Voucherify
• „Cum să utilizați platformele API-First pentru a vă construi site-urile mai rapid”, Michal Sedzielewski, mediu
• „Cum să utilizați prima platformă API pentru a vă pregăti prototipul de producție”, Michal Sedzielewski, mediu
• „Cum să folosiți cloudul pentru a crea aplicații mai rapid”, Michal Sedzielewski, Hacker Noon