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:
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:
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:
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:
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