Aquest article tracta sobre l'arquitectura de programari. Si cerqueu el factor de transcripcio, vegeu ≪ NRSF ≫.

REST ( Representational State Transfer ) es una arquitectura de programari pensada per sistemes distribuits basats en hipermedia , com ara el web . Aquest terme va ser introduit l'any 2000 en una tesi doctoral sobre arquitectures de programari de xarxes. ^[1] Aquesta tesi va ser escrita per Roy Thomas Fielding i dirigida per Richard N. Taylor. Roy va ser un dels principals autors de les especificacions del protocol HTTP i explica en la seva tesi com es pot aprofitar aquest protocol per tal de desenvolupar aplicacions distribuides. Tot i que en un principi REST es referia tan sols a un conjunt de principis d' arquitectura de xarxa i la definicio i adrecament dels recursos, actualment aquest concepte es fa servir per referir-se a una interficie web que utilitza XML , JSON , HTML i HTTP sense cap conjunt de capcaleres com podria ser en el cas de SOAP i XML-RPC . Segons la tesi de Roy es poden dissenyar interficies XML+HTTP seguint la filosofia de Remote Procedure Call sense utilitzar la complexitat del protocol SOAP.

Un servei web REST es un model centrat en les dades. Els anomenats recursos venen identificats per URIs i poden ser manipulats mitjancant accions especificades a les capcaleres HTTP.

Requisits d'un Servei Web RESTful [ modifica ]

De manera formal, perque un servei web es pugui anomenar estrictament RESTful ha de satisfer 6 restriccions (una d'elles opcional). ^{[2] [3]} Acomplint amb les restriccions aconseguim unes propietats desitjables com rendiment, escalabilitat, simplicitat, modificabilitat, portabilitat i fiabilitat.

• Uniform interface . Es tracta de la part fonamental del servei RESTful. Defineix la interficie entre el client i el servidor . Principis:

1. Identificacio dels recursos: Els recursos individuals es troben identificats a les peticions mitjancant URIs. A mes, aquests recursos es troben conceptualment separats de la representacio que es retorna al client.
2. Manipulacio dels recursos per mitja de les seves representacions: El client -sempre que tengui permis i per mitja de la representacio d'un recurs-, te prou informacio per modificar o esborrar aquell recurs al servidor.
3. Missatges autodescriptius: Cada missatge intercanviat entre el client i el servidor conte la informacio necessaria per processar-lo.
4. HATEOAS (Hypermedia as the Engine of Application State): El client interactua amb el servidor per complet mitjancant hypermedia proporcionada dinamicament per aquest segon.

• Client-Server . Separacio client-servidor. D'aquesta manera el client no es preocupa de l'emmagatzematge de les dades i aixi s'aconsegueix que el seu codi font sigui mes portable. Quant al servidor, no es preocupa de l'estat del client, fent que aquest pugui ser mes escalable. El desenvolupament del client i del servidor pot ser independent l'un de l'altre mentre la interficie uniforme entre els dos no sigui alterada.
• Stateless . La comunicacio client-servidor no requereix que el servidor hagi de guardar informacio del client entre peticions consecutives. Com s'ha dit, cada missatge del client conte prou informacio per satisfer la peticio.
• Cacheable . Les respostes del servidor poden guardar-se en una memoria cache, sigui de manera implicita, explicita o negociada. L'objectiu es minimitzar -en els casos en que sigui possible-, les interaccions client-servidor, fent que el client accedeixi a la representacio del recurs guardada en cache i millorant l'escalabilitat i rendiment del sistema.
• Layered system . El client no assumeix que hi ha una connexio directa amb el servidor final. Poden existir sistemes software o hardware entre ells. Per exemple, hi pot haver un servidor intermedi que guardi en cache les respostes del servidor. Un altre exemple seria el d'un servidor intermedi que actui com a balanc de carrega , millorant l'escalabilitat i minvant els danys davant la possibilitat d'haver de fer front a atacs de denegacio de servei ( DDoS ). Altres elements situats entre el client i el servidor final poden ajudar a millorar les politiques de seguretat del sistema.
• Code on demand (opcional) . El servidor -de manera temporal-, pot decidir ampliar la funcionalitat del client transferint-li codi i executant aquesta logica.

REST vs SOAP [ modifica ]

• El millor es utilitzar REST quan sigui necessari tenir representacio diferent d' XML .
• Si el criteri de l'escalabilitat te molt pes dintre del blueprint d'arquitectura, REST es la millor opcio perque permet que tots els recursos presentin la mateixa interficie als clients.
• SOA i Serveis web , estan donats suport sobre estandards i especificacions d'amplia maduresa per exemple W-Security, REST no compta, per exemple, amb una amplia gamma d'estandards.
• Els Web Services poden suportar mes protocols de transport com JMS , SOAP , etc. REST tan sols coneix HTTP .
• Si hem d'oferir serveis de la sindicacio RSS o ATOM , REST es la millor opcio.
• REST es molt lleuger i minimitza el consum d'amplada de banda. Aixo es d'especial importancia si es te en compte que el client es una aplicacio mobil, on sempre es recomanable minimitzar el consum de dades o reduir els temps d'espera quan hi ha mala cobertura.
• REST permet que el format dels missatges sigui flexible. Tant es pot emprar JSON (que es basa en l'estructura dels objectes Javascript) com XML.

Notes [ modifica ]