ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 144
Numărul 143 Numărul 142 Numărul 141 Numărul 140 Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 11
Abonament PDF

Recenzia cărții: RESTful Web Services Cookbook de Subbu Allamaraju

Silviu Dumitrescu
Line manager@Telenav



DIVERSE

Cartea pe care v-o supun atenţiei, intitulată "RESTful Web Services Cookbook" de Subbu Allamaraju, arhitect la Yahoo, face parte dintr-o categorie specială. Ea prezintă un ghid complet pentru scrierea şi consumarea serviciilor web REST, într-un mod independent de limbaj. Aceasta constituie o mare provocare. Din punct de vedere al conceptelor introduse este un material cuprinzător, iar provocarea vine în a găsi care sunt limitele unui anumit mediu de programare în a le implementa.

Ghidul conţine modalităţile de design ale serviciului web REST, atât pe partea de client cât şi pe cea de server, dar rezolvă şi probleme de performanţa, scalabilitate, încredere şi securitate.

Prima informaţie remarcabilă pe care o puteţi afla din această carte a fost că în anul 2000 Roy Fielding a introdus un stil arhitectural cunoscut sub numele de Representational State Transfer (REST) în teza sa de doctorat "Architectural Styles and the Design of Network Based Software Architectures". Gândul meu a zburat imediat în termeni comparativi şi m-am gândit când vom avea şi noi, in România, asemenea teze de doctorat pe tematica arhitecturilor soft. Răspunsul este complicat, cu foarte multă muncă, mă hazardez să afirm că, poate, în zece ani. Viitorul vă aparține!

Voi reveni, totuși, la menirea mea de a vă prezenta cartea curentă. Împărțită în patrusprezece capitole şi cinci anexe, autorul prezintă gradual toate resursele implicate în crearea şi consumarea unui serviciu web REST. Organizarea fiecărui capitol este sub forma unor rețete, adică se ridică o problemă exprimată prin "How to..." sau "When and how...", apoi se dau soluții şi în cele din urmă se poartă discuții.

Serviciile web REST au apărut ca o alternativă la serviciile web bazate pe SOAP. Ele folosesc protocolul HTTP, dar nu sunt limitate doar la acestea. Spre deosebire de SOAP, REST nu necesită parsare de XML, nu necesită un header de mesaj către şi de la service provider. Datorită protocolului de transport HTTP, REST folosește trei metode de comunicare între client şi server:

  • GET, pentru obținerea de informații sigure şi idempotente
  • POST, pentru crearea unei noi resurse, pentru modificarea uneia sau mai multor resurse, pentru a rula cereri cu intrări mari sau pentru a executa orice operații nesigure sau neidempotente, atunci când nici o altă metoda HTTP nu pare potrivită
  • PUT, pentru a crea resurse noi doar atunci când clienții pot decide asupra URI-ului de resurse, altfel se va utiliza POST
  • DELETE, pentru ștergerea unei resurse şi nu numai

Dacă ne referim la entități şi legătura cu un modul de persistență putem avea în vedere folosirea celor patru metode după următorul sablon:

  • GET, pentru interogare
  • PUT, pentru update
  • DELETE, pentru ștergere
  • POST, pentru creare

Tot la nivelul comunicării interesează modul în care grupăm sau combinăm resursele. Aceste acțiuni au relevanță în creșterea performanțelor şi limitarea traficului.

Dupa cum stim, oricare dintre metode poate fi Consumer sau Producer. În plus, fiecare dintre metode își poate impune tipul de resursă pe care îl produce sau consuma. Alegerea tipului de resursă este dificilă. Principalele tipuri de reprezentări pe care autorul le descrie sunt:

  • XML, pentru orice reprezentare
  • JSON, pentru orice reprezentare, dar JSON poate oferi performanță în parsare fața de XML
  • Formate de date portabile precum: data, timp, numere, valuta
  • Date codate binar precum: filme, audio, foto
  • Erori, sub forma unui text plain sau a unui cod de eroare. Codurile de eroare sunt sunt forma 4xx, pentru erori datorate datelor de intrare ale clientului, şi 5xx pentru erori de implementare de pe server sau datorate stării curente

Resursele sunt identificate prin URI. Modul în care este construit URI-ul are o importanță foarte mare în evitarea ambiguităților şi regăsirea resurselor. Autorul descrie multe elemente necesare creării URI-urilor, dar şi unele dintre bunele practici, spre exemplu "How to Keep URIs Cool" în sectiunea 4.4.

Un capitol aparte, capitolul 5, tratează subiectul link-urilor web. Acestea sunt prezente în reprezentarile XML, JSON, in header-e şi la client. Construirea template-urilor URI este eficientă deoarece conferă dinamicitate unui URI, clienții putând să-și includă informații adiționale în URI înaintea trimiterii cererii către server.

Formatele Atom şi AtomPub definesc resurse precum entries şi feeds, reprezentarea lor şi un protocol de operare pe aceste resurse. Serviciile web REST suportă acest tip de format, pe lângă cele anunțate anterior.

De la capitolul 7 încolo autorul prezintă, ceea ce aș numi elemente avansate în cadrul serviciilor REST. Primul subiect atins este acela al negocierii conținutului, mai precis indicării preferințelor clientului precum: tipurile media suportate, limba, codarea caracterelor, etc. .

Problema folosirii cache-ului este foarte importantă pentru că bine folosită conduce la scăderea întârzierilor percepute de utilizator, creșterea încrederii, reducerea costurilor, a încărcării benzii şi a serverului. Bazat pe frecvența update-urilor se poate fixa o perioadă de timp pentru care cache-ul poate servi o reprezentare.

O nouă provocare ce conduce la performanță este dată de cereri condiționale. Acestea adresează două probleme: pentru cereri GET ajută clienții şi cache-ul să identifice dacă o anumită reprezentare poate fi considerată proaspătă, iar pentru cereri PUT, POST şi DELETE cererile condiționale furnizează controlul concurenței. Controlul concurent este implementat în două feluri:

  • Concurența pesimistă: clientul blocând resursa,
  • Concurența optimistă: prin introducerea unui token de versiune ce se validează.

Partea următoare cuprinde topicuri diverse relativ la o resursă, cum poate ea fi copiată, mutată, făcută undo şi multe altele. Capitolul 11 face precizări importante relativ la acestea.

Capitolul de securitate, 12, descrie aspectele legate de accesul la resurse, prin autentificare, precum şi confidențialitate, integritate, prevenirea accesului clientilor rău intenționați sau neautorizați.

Ultimul capitol se referă la extensibilitate şi versionare şi face referiri la menținerea compatibilităților URI, a reprezentărilor XML şi JSON, extinderea atom-ilor, samd.

Mie materialul mi s-a părut foarte cuprinzător. Citirea lui mi-a ridicat câteva probleme, în special pentru că unele dintre capabilități nu le testasem pentru Java. În acest moment nu știu care dintre cele discutate în carte nu pot fi suportate de serverul Glassfish. Majoritatea testelor pe care le-am făcut au reușit, dar există încă multe de testat. Mă adresez de aceea vouă, cititorilor, să incercați implementarea în Java EE 6 a tuturor problemelor pe care autorul le ridică în această carte. Consider că dacă veți reuși să parcurgeți întreg materialul şi să creați exemple ilustrative, REST nu va mai avea neclarități pentru voi. Aștept cu mare plăcere orice discuții!

Ca de obicei, vă doresc lectură plăcută,

Silviu Dumitrescu

NUMĂRUL 143 - Software Craftsmanship

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • P3 group
  • Ing Hubs
  • Cognizant Softvision
  • Colors in projects