REST

Aquest article tracta sobre l'arquitectura de programari. Si cerqueu el factor de transcripció, vegeu «NRSF».

REST (Representational State Transfer) és una arquitectura de programari pensada per sistemes distribuïts basats en hipermèdia, com ara el web. Aquest terme va ser introduït l'any 2000 en una tesi doctoral sobre arquitectures de programari de xarxes. 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 distribuïdes. Tot i que en un principi REST es referia tan sols a un conjunt de principis d'arquitectura de xarxa i la definició i adreçament dels recursos, actualment aquest concepte es fa servir per referir-se a una interfície web que utilitza XML, JSON, HTML i HTTP sense cap conjunt de capçaleres com podria ser en el cas de SOAP i XML-RPC. Segons la tesi de Roy es poden dissenyar interfícies XML+HTTP seguint la filosofia de Remote Procedure Call sense utilitzar la complexitat del protocol SOAP.

Model REST.

Un servei web REST és un model centrat en les dades. Els anomenats recursos venen identificats per URIs i poden ser manipulats mitjançant accions especificades a les capçaleres HTTP.

Requisits d'un Servei Web RESTful

De manera formal, perquè un servei web es pugui anomenar estrictament RESTful ha de satisfer 6 restriccions (una d'elles opcional). 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 interfície entre el client i el servidor. Principis:

1. Identificació dels recursos: Els recursos individuals es troben identificats a les peticions mitjançant URIs. A més, aquests recursos es troben conceptualment separats de la representació que es retorna al client.
2. Manipulació dels recursos per mitjà de les seves representacions: El client -sempre que tengui permís i per mitjà de la representació d'un recurs-, té prou informació per modificar o esborrar aquell recurs al servidor.
3. Missatges autodescriptius: Cada missatge intercanviat entre el client i el servidor conté la informació necessària per processar-lo.
4. HATEOAS (Hypermedia as the Engine of Application State): El client interactua amb el servidor per complet mitjançant hypermedia proporcionada dinàmicament per aquest segon.

• Client-Server. Separació client-servidor. D'aquesta manera el client no es preocupa de l'emmagatzematge de les dades i així s'aconsegueix que el seu codi font sigui més portable. Quant al servidor, no es preocupa de l'estat del client, fent que aquest pugui ser més escalable. El desenvolupament del client i del servidor pot ser independent l'un de l'altre mentre la interfície uniforme entre els dos no sigui alterada.
• Stateless. La comunicació client-servidor no requereix que el servidor hagi de guardar informació del client entre peticions consecutives. Com s'ha dit, cada missatge del client conté prou informació per satisfer la petició.
• Cacheable. Les respostes del servidor poden guardar-se en una memòria cache, sigui de manera implícita, explícita o negociada. L'objectiu és minimitzar -en els casos en què sigui possible-, les interaccions client-servidor, fent que el client accedeixi a la representació del recurs guardada en cache i millorant l'escalabilitat i rendiment del sistema.
• Layered system. El client no assumeix que hi ha una connexió 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 actuï com a balanç de càrrega, millorant l'escalabilitat i minvant els danys davant la possibilitat d'haver de fer front a atacs de denegació de servei (DDoS). Altres elements situats entre el client i el servidor final poden ajudar a millorar les polítiques 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 lògica.

REST vs SOAP

• El millor és utilitzar REST quan sigui necessari tenir representació diferent d'XML.
• Si el criteri de l'escalabilitat té molt pes dintre del blueprint d'arquitectura, REST és la millor opció perquè permet que tots els recursos presentin la mateixa interfície als clients.
• SOA i Serveis web, estan donats suport sobre estàndards i especificacions d'àmplia maduresa per exemple W-Security, REST no compta, per exemple, amb una àmplia gamma d'estàndards.
• Els Web Services poden suportar més protocols de transport com JMS, SOAP, etc. REST tan sols coneix HTTP.
• Si hem d'oferir serveis de la sindicació RSS o ATOM, REST és la millor opció.
• REST és molt lleuger i minimitza el consum d'amplada de banda. Això és d'especial importància si es té en compte que el client és una aplicació mòbil, on sempre és 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.