REST API (RESTful API) (Română)

Acest articol face parte din

ghid pentru construirea unei strategii API întreprindere

• care include, de asemenea:
• 5 motive majore pentru a adopta o platformă de management API
• 10 orientări de securitate API și cele mai bune practici
• limba internetului. Cu utilizarea cloud în creștere, API-urile sunt utilizate de consumatorii cloud pentru a expune și organiza accesul la serviciile web., REST este o alegere logică pentru construirea API-urilor care permit utilizatorilor să se conecteze, să gestioneze și să interacționeze flexibil cu serviciile cloud într-un mediu distribuit. API-urile RESTful sunt utilizate de site-uri precum Amazon, Google, LinkedIn și Twitter.

  cum funcționează API-urile RESTful

  un API RESTful descompune o tranzacție pentru a crea o serie de module mici. Fiecare modul se adresează unei părți subiacente a tranzacției. Această modularitate oferă dezvoltatorilor multă flexibilitate, dar poate fi o provocare pentru dezvoltatori să își proiecteze API-ul REST de la zero., În prezent, mai multe companii oferă modele pentru dezvoltatori; modelele furnizate de Amazon S3, Cloud Data Management Interface (CDMI) și OpenStack Swift sunt cele mai populare.

  un API RESTful utilizează comenzi pentru a obține resurse. Starea unei resurse în orice moment dat se numește reprezentare a resurselor., Un API Odihnitor folosește existente HTTP metodologii definite prin RFC 2616 protocol, cum ar fi:

  • IA de a prelua o resursă;
  • PUNE pentru a schimba starea de actualizare sau o resursă, care poate fi un obiect, fișier sau bloc;
  • MESAJ pentru a crea acea resursă; și
  • ȘTERGERE pentru a elimina.

  cu REST, componentele în rețea sunt o resursă la care utilizatorul solicită acces-ca o cutie neagră ale cărei detalii de implementare sunt neclare. Toate apelurile sunt apatride; nimic nu poate fi reținut de serviciul odihnitor între execuții.,

  formate de Date API-ul REST sprijină includ:

  • application/json
  • application/xml
  • application/x-wbe+xml
  • application/x-www-form-urlencoded
  • multipart/form-data

  Folosește

  Pentru apelurile sunt apatrizi, RESTUL este util în aplicații de tip cloud. Componentele apatride pot fi redistribuite liber dacă ceva nu reușește și pot scala pentru a se adapta schimbărilor de sarcină. Acest lucru se datorează faptului că orice solicitare poate fi direcționată către orice instanță a unei componente; nu poate fi salvat nimic care trebuie amintit de următoarea tranzacție., Acest lucru face ca odihna să fie preferabilă pentru utilizarea web. Modelul RESTful este, de asemenea, util în serviciile cloud, deoarece legarea la un serviciu printr-un API este o chestiune de control al modului în care este decodificată adresa URL. Cloud computing și microservicii sunt aproape sigur de a face RESTful API design regula în viitor.

  RESTful API design și constrângeri de arhitectură

  RESTful API design a fost definit de Dr. Roy Fielding în disertația sa de doctorat din 2000., Pentru a fi un adevărat API RESTful, un serviciu web trebuie să adere la următoarele șase constrângeri arhitecturale REST:

  • utilizarea unei interfețe uniforme (UI). Resursele ar trebui să fie identificabile în mod unic printr-o singură adresă URL și numai prin utilizarea metodelor de bază ale Protocolului de rețea, cum ar fi ștergerea, punerea și obținerea cu HTTP, ar trebui să fie posibilă manipularea unei resurse.
  • bazat pe Client-server. Ar trebui să existe o delimitare clară între client și server. UI și preocupările de colectare a cererilor sunt domeniul clientului., Accesul la date, gestionarea volumului de muncă și securitatea sunt domeniul serverului. Această cuplare liberă a clientului și a serverului permite ca fiecare să fie dezvoltat și îmbunătățit independent de celălalt.
  • apatrizi operațiuni. Toate operațiunile client-server ar trebui să fie apatride, iar orice management de stat care este necesar ar trebui să aibă loc pe client, nu pe server.
  • RESTful resurse cache. Toate resursele ar trebui să permită cache-ul, cu excepția cazului în care se indică în mod explicit că cache-ul nu este posibil.
  • sistem stratificat. REST permite o arhitectură compusă din mai multe straturi de servere.,
  • cod la cerere. De cele mai multe ori, un server va trimite înapoi reprezentări statice ale resurselor sub formă de XML sau JSON. Cu toate acestea, atunci când este necesar, serverele pot trimite cod executabil clientului.

  provocări comune API REST

  pe lângă constrângerile de design și arhitectură, indivizii vor trebui să se confrunte cu unele provocări cu API-urile REST. Unele concepte care pot fi provocatoare pot include:

  • Endpoint consistence — căile punctelor finale ar trebui să fie consecvente urmând standarde web comune, care pot fi dificil de gestionat.,
  • API versioning — URL-urile punctului final nu ar trebui să fie invalidate atunci când sunt utilizate intern sau cu alte aplicații.
  • timpii lungi de răspuns și prea multe date-cantitatea de resurse returnate poate crește în dimensiune în timp, adăugând la creșterea timpului de încărcare și răspuns.
  • căi de navigare și locații de introducere a utilizatorului – deoarece REST utilizează căi URL pentru parametrii de intrare, determinarea spațiilor URL poate fi o provocare.,
  • Securitate-care are o mulțime de aspecte pentru a păstra un ochi pe, inclusiv utilizarea de:
    • HTTPS;
    • blocarea accesului la necunoscut adrese IP și domenii;
    • validarea Url-uri;
    • blocarea neașteptat de utile mari;
    • logare cereri; și
    • investigare eșecuri.
  • autentificare — utilizați metode comune de autentificare, cum ar fi autentificarea de bază HTTP (care permite un nume de utilizator codificat base64:șir de parole), chei API, Jetoane web JSON și alte jetoane de acces. OAuth 2.0, de exemplu, este bun pentru controlul accesului.,
  • cereri și date — cererile pot avea mai multe date și metadate decât este necesar sau pot fi necesare mai multe solicitări pentru a obține toate datele. API-urile pot fi ajustate pentru acest lucru.
  • testarea API – poate fi un proces lung de configurat și rulat. Fiecare parte a procesului poate fi lungă sau provocatoare. Testarea se poate face și în linia de comandă cu utilitarul Curl., Părți ale procesului de testare care pot fi provocatoare includ:
    • configurare Inițială
    • Schema actualizări
    • parametru de Testare combinații
    • Secvența de apeluri API
    • Valida parametrii de testare
    • integrare de Sistem
  • Defini coduri de eroare și mesaje.
    • cu coduri de eroare, este mai mult o practică obișnuită de a utiliza coduri de eroare HTTP standard. Acestea sunt recunoscute mai des de clienți și dezvoltatori.
    • manipularea erorilor poate să nu aibă o modalitate de a distinge dacă un răspuns are succes sau nu, pe lângă analizarea corpului sau verificarea unei erori.,

  REST vs. SOAP

  REST și Simple Object Access Protocol (SOAP) oferă diferite metode pentru a invoca un serviciu web. Restul este un stil arhitectural, în timp ce SOAP definește o specificație standard a Protocolului de comunicare pentru schimbul de mesaje bazat pe XML. Aplicațiile de odihnă pot folosi săpun.serviciile web RESTful sunt apatride. O implementare bazată pe REST este simplă în comparație cu SOAP, dar utilizatorii trebuie să înțeleagă contextul și conținutul transmis, deoarece nu există un set standard de reguli pentru a descrie interfața serviciilor web REST., Serviciile REST sunt utile pentru dispozitivele cu Profil restricționat, cum ar fi dispozitivele mobile, și sunt ușor de integrat cu site-urile web existente.

  SOAP necesită mai puțin cod sanitar-adică un cod de infrastructură de nivel scăzut care conectează modulele principale de cod împreună-decât designul serviciilor REST. Limbajul de descriere a serviciilor web descrie un set comun de reguli pentru a defini mesajele, legăturile, operațiunile și locația serviciului. Serviciile web SOAP sunt utile pentru procesarea și invocarea asincronă.înainte de REST, dezvoltatorii au folosit SOAP pentru a integra API-uri., Pentru a efectua un apel, dezvoltatorii au scris manual un document XML cu un apel de procedură la distanță (RPC) în organism. Apoi au specificat punctul final și au postat plicul de săpun la punctul final.în 2000, Roy Fielding și un grup de dezvoltatori au decis să creeze un standard, astfel încât orice server să poată vorbi cu orice alt server. El a definit odihna și constrângerile arhitecturale explicate mai sus în teza sa de doctorat din 2000 la Universitatea din California, Irvine. Aceste reguli universale facilitează dezvoltatorilor integrarea software-ului.,Salesforce a fost prima companie care a vândut un API ca parte a pachetului său” Internet ca serviciu ” în 2000. Cu toate acestea, puțini dezvoltatori au reușit să utilizeze API-ul XML complicat. Apoi eBay a construit un API REST, care și-a extins piața pe orice site care ar putea accesa API-ul său. Acest lucru a atras atenția unui alt gigant de comerț electronic, iar Amazon și-a anunțat API-ul în 2002.Flickr a lansat propriul API RESTful în August 2004, permițând bloggerilor să încorporeze cu ușurință imagini pe site-urile lor și în fluxurile de socializare., Facebook și Twitter și-au lansat API-urile în 2006, flambând sub presiunea dezvoltatorilor care au răzuit site-urile și au creat API-uri „Frankenstein”. Când Amazon Web Services (AWS) a ajutat la lansarea norului în 2006, dezvoltatorii au putut accesa spațiul de date în câteva minute folosind API-ul REST AWS, iar cererea de API-uri publice a escaladat rapid.de atunci, dezvoltatorii au adoptat API-uri RESTful, folosindu-le pentru a adăuga funcționalitate site-urilor și aplicațiilor lor. Astăzi, API-urile REST sunt considerate „coloana vertebrală a internetului.”