La arquitectura REST (Representational State Transfer) es un estilo de distribución de datos mediante la web aprovechando el protocolo HTTP (métodos, URIs, Media Types, codigos de respuesta y petición…). Básicamente consiste en clientes que realizan peticiones a servidores, estos las procesan y retornan la respuesta adecuada.
Tanto las peticiones como las respuestas intentan “representar recursos” (de ahí su nombre), entendiendo un recurso como “contenido” que puede ser accedido a partir de una dirección.
En cualquier momento la aplicación cliente entrará en una transición de “estados de aplicación” (transición entre las distintas acciones que realiza una aplicación), se dice que si la aplicación entra en un estado “de descanso” (at rest) el usuario podrá interactuar con ella pero esta no cargará ni consumirá datos. La aplicación cliente enviará peticiones cuando esté preparada para una nueva transición.
Un servicio REST asegura rendimiento, escalabilidad, simplicidad, modificabilidad, visibilidad portabilidad y confiabilidad.

Las reglas a seguir en una arquitectura de estilo REST son las siguientes, si se siguen todas (excepto 'código on demand') el servicio podrá ser denominado RESTful:

1. Cliente - Servidor: La interface de cliente está separada del servidor, esto significa que no pueden acceder directamente a los datos si no es a partir del mismo servidor. Por otra parte tanto el cliente como el servidor son independientes y han de ser desarrollados por separado.
2. Sin estados: Las peticiones del cliente se harán de una en una y no por partes, cada una de estas contendrán toda la información necesaria para realizarla. Las peticiones se harán a partir de una URL.
3. Cacheable: Los clientes han de ser capaz de guardar en caché las respuestas del servidor.
4. Sistema por capas: Pueden existir servidores intermedios que mejoren la escalabilidad del sistema permitiendo el balanceo de carga y compartir cachés.
5. Código on demand (opcional): El servidor puede ser capaz de transferir código al cliente para ser ejecutado en él (como por ejemplo JavaScript).
6. Interface uniforme: Esto simplifica y desacopla la arquitectura, lo que permite a cada parte evolucionar independientemente. En una interface uniforme…
   • Los recursos han de estar identificados en las peticiones. Esto significa que el servidor enviará los datos correctamente identificados en el formato que sea (HTML, XML, JSON…) y estos pueden ser una porción de la DB.
   • Los recursos pueden ser manipulados. Esto significa que si el cliente tiene suficiente información del recurso y a la vez tiene suficientes permisos podrá realizar sobre este acciones de modificación, de borrado…
   • Mensajes autodescriptivos. Cada mensaje ha de incluir suficiente información para que este pueda ser procesado.
   • Los recursos han de ser reconocidos por métodos de hypermedia (como por ejemplo URIs).

De forma distinta a los web services basados en SOAP no existe un standard oficial (a parte de las reglas ya nombradas) para que un servicio sea RESTful, esto es porque REST es una arquitectura y SOAP un protocolo. Se definen tres aspectos para un servicio REST común:

• La URI base del web service, como por ejemplo: http://example.com/resources/
• El tipo de dato devuelto (MIME type). JSON, XML, YAML…
• Las operaciones soportadas usando los método HTTP (por ejemplo PUT, GET, POST o DELETE).

Ejemplo:

Mientras que en otro tipo de web services se pone énfasis en los verbos (getUser(data), updateUser(data)…) en REST se pone énfasis en los nombres (User {data}). Un recurso tendría su propio identificador, como por ejemplo http://www.example.org/locations/us/ny/new_york_city donde, si se accede a partir del método GET, podrían haber los datos de la ciudad de New York, además puede ser sencillamente cacheado, copiado y guardado como marcador.

El protocolo HTTP es un protocolo cliente-servidor que se implementa a nivel de aplicación y define operaciones sobre los recursos del servidor (como GET, POST, PUT y DELETE), esto evita al desarrollador que lo utilice incorrectamente (es decir que siga la regla de Interface Uniforme) tener que inventar nuevos métodos (como getClients o updateStops).

• Fuente: http://www.prescod.net/rest/mistakes/

Los errores que se llevan a cabo en el desarrollo de servicios REST son:

1. No seguir los estándards HTTP.
2. Utilizar POST para otros fines que no sea la creación de un nuevo elemento.
3. Depender de la estructura del servidor. Las URIs deberían ser configurables.
4. Utilizar acciones en las URIs. Por ejemplo “someuri?action=delete” es erróneo.
5. Usar sesiones. Las aplicaciones son consumidores de recursos, no servicios.
6. No utilizar las URIs correctamente. Para acceder a un recurso haríamos “someuri/resource/322” o utilizaríamos RDF.
7. Preocuparse por el protocolo.