You are on page 1of 14

RESTful

Web Services

Servicios Web basados en la arquitectura REST


Arquitectura REST (Representation State Transfer)

Fue descrita por primera vez en una tesis doctoral Architectural Styles and the Design of Network-based Software Architectures
Su autor Roy Thomas Fielding es ademas uno de los principales autores de las especificaciones HTTP y cofundador del proyecto
Apache HTTP Server

REST es un estilo arquitectonico hibrido derivado de otros estilos arquitectonicos de red y combinado con restricciones adicionales
aplicadas a sus elementos que define una interfaz de conexion uniforme

Restriccciones:
Cliente-Servidor: Separacion de responsibilidades. Por un lado la interfaz del usuario y por otro el almacenamiento de los datos. Esto
permite una evolucion independiente de los componentes.

Statless: L a comunicacion cliente-servidor debe ser sin estado. Cada request del cliente debe contener toda la informacion
necesaria para que el servidor entienda la solicitud. Por lo tanto el estado de la sesion se mantiene totalmente en el cliente

Cache: La informacion de una respuesta a un REQUEST debe ser etiquetada como cacheable o no cacheable. Un usuario podra
reutilizar una respuesta anterior.Esto evita parcial o tatalmente una nueva interaccion con el servidor

Interfaz Uniforme entre Componentes: La informacion se transmite en forma estandarizada. Se necesitan 4 restricciones de
interfaz:
Identificacion de los recursos: Los recursos se identifican en forma individual utilizando URIs. Estan conceptualmente
separados de la representacion que se envian al cliente.
Manipulacion de los recursos a traves de las representaciones: Una vez que el cliente almacena la representacion de un
recurso tiene informacion suficiente para modificarlo en el servidor.
Mensajes autodescriptivos: Cada mensaje incluye informacion suficiente para describir como se lo debe procesar.
Hypermedia como el motor del estado de la aplicacion: Los clientes entregan el estado utilizando: cuerpo del contenido,
los parametros del string de consulta, los headers del REQUEST y la URI solicitada. Los servicios entregan el estado a los
clientes utilizando: cuerpo del contenido, codigo de respuestas y headers. Esto es tecnicamente la hipermedia (hiperlinks
con texto).
Sistema de Capas: Restringe la vision del sistema a una sola capa para evitar sobrecargas y latencias. En pocas palabras el cliente
no puede saber si esta conectado directamente con el servidor o a un intermediario. Los ervidores intermedios pueden mejorar
el balance de carga y aplicar politicas de seguridad

Codigo On-Demand: La funcionalidad del cliente se puede extender bajando y ejecuntando codigo en forma de aplets o scripts.
Interfaz Uniforme Decalaracion de Elementos

La declaracion de interfaz uniforme REST se basa en tres elementos fundamentales

1. Sintaxis de Identificador de Recurso: Es la forma en que podemos expresar donde estan los datos a transferir. Se utiliza sintaxis URI.
Se asigna ID unico a cada recurso del servicio.
2. Metodos: Son los mecanismos utilizados por el protocolo para procesar los recursos. HTTP provee metodos genericos: GET, PUT,
POST, DELETE, HEAD y OPTIONS
3. Tipo de medio: Tipo de dato que se transfiere. Los mas utilizados con HTTP estan registrados con IANA, y siguen una sintaxis
estandarizada.
http://www.iana.org/assignments/media-types/media-types.xhtml

La utilizacion de una interfaz uniforme hace que los request y response sean auto-descriiptivos y visibles.
Interfaz Uniforme Identificacion de Recursos (URIs)

Una URI es una cadena de caracteres que se utiliza para identificar el nombre de un recurso. Esta identificacion permite la interaccion
con las representaciones del recurso en la red, utilizando protocolos especificos.

Las sintaxis generica de una URI consiste en una secuencia jerarquica de componentes : esquema, autoridad, path, query, fragmento.
Utiliza los caracteres reservados / ? # para delimitar los componentes significativos

foo://example.com:8042/over/there?name=ferret#nose
\_/ \______________/\_________/ \_________/ \__/
| | | | |
esquema autoridad path query fragmento
Interfaz Uniforme Ejemplo URI completa
Interfaz Uniforme Utilizacion de los metodos HTTP

Recurso GET PUT POST DELETE

http://www.domain.com/ Obtener lista Remplazar la Crear una nueva entidad en la lista y Borar la lista entera
listado/productos de las lista entera asignar el ID automaticamente.
entidades Devolver el ID en la respuesta

http://www.domain.com/ Obtener una Actualizar la Tratar la entidad como lista en si Borrar la entidad sealada de
listado/productos/145 representacio entidad o misma la lista
n de la crearla con
entidad un ID
especifico
Interfaz Uniforme Significado de los Metodos HTTP

METODO IDEMPOTENTE SEGURO SIGNIFICADO

GET SI SI Obetener una entidad o lista de entidades desde el recurso

PUT SI NO Reemplazar la entidad del recurso

POST NO NO Agregar una entidad a la lista enviandola al recurso / crear un nuevo recurso

DELETE SI NO Borrar una entidad del recurso / destruir el recurso

OPTIONS SI SI Obtener los metadatos que describen que se puede hacer con el recurso

HEAD SI SI Obtener los metadatos (encabezados) del recurso pero no el body

TRACE SI SI Realiza un test de loop-back alo largo del path hacia el recurso indicado

CONNECT SI SI Establece un tunel al servidor de la URI indicada

GET,HEAD, OPTIONS, TRACE se consideran seguros porque su proposito es obtener informacion y no modifician el recurso en el servidor
GET,HEAD,PUT,DELETE son operaciones idempotentes porque siempre se obtiene el mismo resultado aunque se ejecuten multiples veces
Interfaz Uniforme Significado Codigos de Estado HTTP

Codigos de estado mas frecuentes

Status Meaning
200 OK Request processed and answered successfully. No error.
201 CREATED Creation of resource was successful.
202 ACCEPTED Creation of resource was successful but actual work is onducted asynchronously.
304 NOT MODIFIED Resource hasn't changed since the time specified in the request's If-Modified-Since header.
400 BAD REQUEST Invalid request URI or header, or unsupported nonstandard parameter.
401 UNAUTHORIZED Authorization required or not successful.
403 FORBIDDEN Unsupported standard parameter or HTTP method not allowed.
404 NOT FOUND Resource (such as a list or entity not found.
500 INTERNAL SERVER ERROR Internal error. This is the default code that is used for all unrecognized errors

Listado completo con todos codigos de estado HTTP


Interfaz Uniforme Encabezados HTTP

Header Category Meaning


Location Resource Creation Location of resource where new entity can be retrieved
Authorization Security Header to provide authorization information
WWW-Authenticate Security Header that tells you what security protocol to use
Expires Caching Tells you when retrieved representation expires.
Last-Modified Validity Tells you when representation was last modified.
If-Modified-Since Validity Used to check whether updates for your own label representation are available.
ETag Validity Tells you when representation was last modified
If-None-Match Validity Used to check whether updates for representation are available
Accept Representation Tells server, which content type we accept, e.g. text/plain
Accept-Encoding Representation Tells server, which encoding we want, e.g. gzip.
Accept-Language Representation Tells server, which language we understand, e.g. de_DE
Content-Type Representation Tells client and intermediaries of which content type the representation is
Content-Encoding Representation Tells client and intermediaries of which encoding the representation is
Tells client and intermediaties of which your own label language the returned
Content-Language Representation
representation is
Tells Cache which headers to consider when caching representations. Cache-Control
Vary Caching
Caching Tells intermediaries how to cache given representation.

W3C RFC2616 - Capitulo 14 - Header Fields Definitions


Listado completo de encabezados de HTTP
Interfaz Uniforme Datos MIME-Type

Los media type consisten en un nombre de nivel superior y subtipos estructurados en arbol. Opcionalmente pueden incluir
parametros como informacion adicional

top-level type name / subtype name [ ; parameters ]

Los nombres registrados de top-level son:

application audio example image


Message model multipart text video

Ejemplos:

application/xhtml+xml
image/png
image/svg+xml
application/vnd.oasis.opendocument.text
text/plain; charset=utf-8
video/mp4; codecs=avc1.640028

Listado completo de MIME Types


REST vs SOAP

REST SOAP

El transporte debe ser HTTP o HTTPS Normalmente HTTP/HTTPS pero pueden utilizar otros como ftp, SMTP etc..

Los datos de la respuesta se transmiten en


Los datos se transmiten como XML
cualquier formato

Los request se transmiten como URIs livianas, e Los request se transmiten como XML. Para entender la solicitud se debe
indican el objeto pretendido analizar el cuerpo del mensaje

Pueden necesitar parseo Json, XML o solo HTML Nececita parseo XML
Sencillos de construir Es comun utilizar IDEs o herramientas de desarrollo
Las operaciones se definen en los mensajes Las operaciones son definidas como puertos WSDL
Una direccin nica para cada instancia del
Direccin nica para todas las operaciones
proceso
Cada objeto soporta las operaciones indicades del
Se definen funciones en cada implementacion WSDL/server
estandares de HTTP
Generalmente facil de construir y adoptar Recomendable la utilizacion de un IDE
Los clientes necesitan conocer las operaciones y su semantica antes del
Gran numero de objetos
uso
Funciones y clases de PHP para RESTful WS

file_get_contents
curl
SimpleXML
jsonencode
jsdecode
Modelo Practico

REST es mas una coleccion de principios que un estandard. Se basa y utliza estandares HTTP, MIME etc..

A los efectos de implementar practicamente una interfaz RESTful lo haremos en forma de guia y no mediante un analisis desde el
punto de vista del modelo de arquitectura.

1. Identificar todas la unidades conceptuales que se desean exponer como servicio


2. Crear una URL para cada recurso utilizando sustantivos que los describan
3. Categorizar los recursos en solo consulta (GET) o modificables (POST, PUT , DELETE)
4. Incluir hipervinculos dentro de la representacion de un recurso para permitir mas informacion
5. Especificar el formato de los datos de respuesta
6. Generar codigos de estados
7. Generar documento con la informacion necesaria para poder invocar y utilizar el servicio

You might also like