REST es un estilo de arquitectura para servicios web que se basa en estándares como HTTP. La web sigue este estilo REST donde los recursos se identifican mediante URIs y pueden manipularse usando verbos HTTP como GET, POST, PUT y DELETE. REST ofrece ventajas como escalabilidad e interoperabilidad para sistemas distribuidos.

1. INTRODUCCIÓN
REST (Representational State Transfer), que en español significa Transferencia de estado
representacional, es cualquier arquitectura de servicios distribuidos, como la web, REST es
solo un estilo de arquitectura, aunque REST no es un estándar, está basado en estándares
como: HTTP, URL, Representación de los recursos: XML/HTML/GIF/JPEG/ y Tipos
MIME: text/xml, text/html.
El estilo de arquitectura subyacente a la Web es el modelo REST, por lo cual Rest captura
las características de la web que la han hecho tan exitosa. Los objetivos de este estilo de
arquitectura son los siguientes:
- Escalabilidad de la interacción con los componentes; una prueba de ellos es la
variedad de clientes que pueden acceder a través de la Web.
- Generalidad de interfaces. Gracias al protocolo HTTP, cualquier cliente puede
interactuar con cualquier servidor HTTP sin ninguna configuración especial.
- Compatibilidad con componentes intermedios, como tipos de proxys para Web,
algunos de ellos, las caches; otros permiten reforzar las políticas de seguridad:
firewalls. Y por último Gateway que permiten encapsular sistemas no propiamente
Web.
Rest es una familia de arquitecturas, cualquier arquitectura de servicios distribuidos que
cumpla con una serie de requisitos se considera como una arquitectura REST.
En una arquitectura REST, los servicios no publican un conjunto arbitrario de métodos u
operaciones, lo que se publica son recursos y un recurso se puede considerar como una
entidad que tiene un estado y un comportamiento, que puede ser accedido públicamente.
Cada recurso, posee un identificador único y global, que lo distingue de otros, aunque
ambos tuvieran exactamente los mismos datos. Cada recurso posee un estado interno, que
no puede ser accedido directamente desde el exterior.
Una representación de un recurso podría ser un documento XML con la información
accesible de este, otra representación sería un documento HTML, o un JSON.
En REST todos los recursos comparten una interfaz única y constante, y tienen las mismas
operaciones, las cuales nos permiten manipular el estado público del recurso.
En un sistema REST se pueden definir cuatro operaciones:
CREATE.- El cliente envía una petición al servidor para crear un nuevo recurso.
DELETE.- El cliente elimina un recurso del servidor.
READ.- El cliente puede leer una representación del estado de un recurso.

2. UPDATE.- El cliente puede sobrescribir o grabar su copia del estado en el servidor,
actualizando el estado del recurso.
Estas operaciones se las puede realizar mediante los verbos (GET, POST, DELETE,
PUT).
HISTORIA
REST fue introducido y definido en el año 2000 por Roy Thomas Fielding en su tesis
doctoral en la Universidad de California en Irvine. (Capítulo 5 tesis doctoral, 2000).
Todo esto comienza desde los inicios de internet, de hecho la web está armada en un
estilo de arquitectura llamado REST.
REST toma elementos de arquitecturas presentes en ese momento, algunas de las cuales
siguen en plena vigencia (particularmente, arquitecturas cliente servidor).
REST fue desarrollada de manera paralela a HTTP 1.0 y 1.1; las funcionalidades de
REST y HTTP se concibieron apoyándose mutuamente y también sobre identificadores
de recursos uniformes (URI).
Cuando se desarrolló REST, su propósito era crear un modelo de arquitectura que
indique como debería funcionar la Web. REST ha sido aplicado para describir la
arquitectura Web deseada, ayudar a identificar problemas existentes, comparar
soluciones alternativas, y asegurar que el protocolo no viole las restricciones que hacen
que la Web funcione correctamente.
REST ha ido evolucionando, pero posteriormente, se le ha ido dando forma para que
encaje perfectamente en el mundo Web, usando las tecnologías existentes (URI, HTTP y
XML), pero el uso de estas tecnologías, puede significar renunciar a parte de su esencia.
Cuando Roy T. Fielding creó REST su disertación, perseguía unos objetivos muy
concretos:
• Escalabilidad de los componentes de interacción.
• Generalidad de las interfaces.
• Independencia en el desarrollo de componentes.
• Sistemas intermedios para reducir el tiempo de interacción
• Mejorar la seguridad, y encapsular los sistemas de herencia.

3. OVERVIEW
La web, y el protocolo HTTP es una arquitectura REST.
REST considera a toda información de la web como un recurso, ya sea un vídeo, archivos
pdf, imágenes, texto plano, entre otros, los cuales tienen un identificador (URI).
La interacción con los recursos se lleva a cabo mediante una interfaz uniforme de los
verbos estándar HTTP (GET, POST, PUT y DELETE), que son similares a los métodos
CRUD (Create, Read, Update, Delete) de una base de datos.
Los recursos deben ser auto-descriptivo para procesar una solicitud de un recurso está
contenido dentro de la misma petición y que dicha respuesta indicará también su
almacenamiento en cache.
Una de las características de REST es que se centra en la escalabilidad y rendimiento para
los sistemas distribuidos.
La diferencia con otras arquitecturas para la solicitud de información como SOAP es que
no necesita de muchas operaciones para invocar un recurso.
En la figura 1 se aprecia como SOAP necesita del WDSL (Lenguaje Descriptor de
Servicios Web) para determinar una función que al final devuelva un recurso, en cambio
REST solo con los métodos del protocolo HTTP solicita fácilmente el recurso.
Fig 1. Diferencia entre SOAP y Rest

4. En resumen Rest cumple con las siguientes restricciones:
Cliente-servidor.- Maneja la arquitectura Cliente-Servidor en donde la interfaz con el
usuario y la lógica del negocio se encuentran separadas.
Fig 2. Arquitectura cliente-servidor
Sin estado.- No se llevará un registro de las transacciones tanto request y response,
simplemente se transferirá la información.
Fig 2. Modelo sin estado en donde no se lleva registro

5. Caché.- Las respuestas a una petición deben poder ser etiquetadas como cacheable o no
cacheable. En caso de ser almacenado en caché el cliente tiene permiso de reutilizar la
respuesta más tarde, siempre que la petición sea equivalente.
Fig 3. Información guardada en caché
Interfaz uniforme.- Para hacer eficiente la transferencia de datos, REST utiliza los verbos
(GET, POST, DELETE, PUT); para manipular los recursos siempre y cuando tenga un
identificador (URI). Además dicha peticiones deben contener el estado de la misma debido
a que REST no se encarga de los estados.
Sistema de capas.- REST maneja la escabilidad, para ello existe una jerarquía de capas, en
donde cada cuenta con las funcionalidades, mejorando el procesamiento de la información.
Fig 4. Sistemas por capas, cada una cumple su función

6. Tecnología y/o Framework
Tecnología Descripción
Tonic Es una librería para PHP para utilizar la
técnica REST en el desarrollo de
aplicaciones.
FRAPI Framework para el desarrollo de aplicaciones
que utilizaran REST en donde se utiliza el
lenguaje de programación PHP.
Jersey Es un framework que utiliza la API JAX-RS
para crear servicios Web Rest en java.
ASP.NET WEBAPI Framework para el desarrollo de los
servicios Web que usan REST con el
lenguaje C#
Slim Un micro framework para construcción de
aplicaciones Web.
Apify Un framework similar a FRAPI, utiliza el php
para el desarrollo de Servicios Web.

7. CONCLUSIONES
 La web es un ejemplo perfecto de servicios distribuidos a nivel global totalmente
interoperable, por lo tanto la web, y el protocolo HTTP es una arquitectura REST,
porque se dedican a hacer GETs sobre URIs para obtener representaciones de las
distintas páginas web.
 Los servicios REST son mejores que SOAP, porque HTTP es un protocolo que
sigue los principios REST, por lo tanto hacer servicios REST es algo que aprovecha
toda la infraestructura de la web ya existente, es decir es usar el propio protocolo
HTTP, los servicios REST tienen menor acoplamiento que los servicios basados en
SOAP, aunque SOAP está ganando en cuanto a seguridad, enrutamiento y otros
aspectos que no pueden ser direccionados con HTTP

8. BIBLIOGRAFÍA.
“REPRESENTATIONAL STATE TRANSFER: REST”, (s.f.). Consultado el 15 de noviembre del
2014. Recuperado de: http://bibing.us.es/proyectos/abreproy/11247/fichero/Memoria%252F8-
Representational+State+Transfer+(REST).pdf
Roy Thomas F. (2000) Architectural Styles and the Design of Network -based Software
Architectures. University of California, Irvine. Recuperado de:
http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
“RESTFUL API FRAMEWORKS EN PHP”, 3 de abril de 2012. Consultado el 15 de noviembre de
2014. Recuperado de: http://qbit.com.mx/blog/2012/04/03/restful-api-frameworks-en-php/
http://www.adwe.es/general/colaboraciones/servicios-web-restful-con-http-parte-i-introduccion-y-
bases-teoricas