La transferencia de estado representacional (en [inglés](https://es.wikipedia.org/wiki/Idioma_ingl%C3%A9s "Idioma inglés") *representational state transfer*) o REST es un estilo de arquitectura *software* para sistemas [hipermedia](https://es.wikipedia.org/wiki/Hipermedia "Hipermedia") distribuidos como la [World Wide Web](https://es.wikipedia.org/wiki/World_Wide_Web "World Wide Web"). El término se originó en el año [2000](https://es.wikipedia.org/wiki/2000 "2000"), en una tesis doctoral sobre la web escrita por [Roy Fielding](https://es.wikipedia.org/wiki/Roy_Fielding "Roy Fielding"), uno de los principales autores de la especificación del protocolo [HTTP](https://es.wikipedia.org/wiki/HTTP "HTTP") y ha pasado a ser ampliamente utilizado por la comunidad de desarrollo. ## Descripción Si bien el término *REST* se refería originalmente a un conjunto de principios de arquitectura —descritos más abajo—, en la actualidad se usa en el sentido más amplio para describir cualquier interfaz entre sistemas que utilice directamente [HTTP](https://es.wikipedia.org/wiki/HTTP "HTTP") para obtener datos o indicar la ejecución de operaciones sobre los datos, en cualquier formato ([XML](https://es.wikipedia.org/wiki/XML "XML"), [JSON](https://es.wikipedia.org/wiki/JSON "JSON"), etc) sin las abstracciones adicionales de los protocolos basados en patrones de intercambio de mensajes, como por ejemplo [SOAP](https://es.wikipedia.org/wiki/Simple_Object_Access_Protocol "Simple Object Access Protocol"). Es posible diseñar sistemas de servicios web de acuerdo con el estilo arquitectural REST de Fielding y también es posible diseñar interfaces [XMLHTTP](https://es.wikipedia.org/wiki/XMLHttpRequest "XMLHttpRequest") de acuerdo con el estilo de [llamada a procedimiento remoto](https://es.wikipedia.org/wiki/Remote_Procedure_Call "Remote Procedure Call") (RPC), pero sin usar SOAP. Estos dos usos diferentes del término *REST* causan cierta confusión en las discusiones técnicas, aunque [RPC](https://es.wikipedia.org/wiki/Remote_Procedure_Call "Remote Procedure Call") no es un ejemplo de REST. REST afirma que la web ha disfrutado de escalabilidad como resultado de una serie de diseños fundamentales clave: * Un protocolo cliente/servidor [sin estado](https://es.wikipedia.org/wiki/Protocolo_sin_estado "Protocolo sin estado"): cada mensaje HTTP contiene toda la información necesaria para comprender la petición. Como resultado, ni el cliente ni el servidor necesitan recordar ningún estado de las comunicaciones entre mensajes. Sin embargo, en la práctica, muchas aplicaciones basadas en HTTP utilizan cookies y otros mecanismos para mantener el estado de la sesión (algunas de estas prácticas, como la reescritura de URLs, no son permitidas por REST) * Un conjunto de operaciones bien definidas que se aplican a todos los *recursos* de información: HTTP en sí define un conjunto pequeño de operaciones, las más importantes son POST, GET, PUT y DELETE. Con frecuencia estas operaciones se equiparan a las operaciones [CRUD](https://es.wikipedia.org/wiki/CRUD "CRUD") en bases de datos (CLAB en castellano: crear,leer,actualizar,borrar) que se requieren para la persistencia de datos, aunque POST no encaja exactamente en este esquema. * Una sintaxis universal para identificar los recursos. En un sistema REST, cada recurso es direccionable únicamente a través de su [URI](https://es.wikipedia.org/wiki/Uniform_Resource_Identifier "Uniform Resource Identifier"). * El uso de hipermedios, tanto para la información de la aplicación como para las transiciones de estado de la aplicación: la representación de este estado en un sistema REST son típicamente [HTML](https://es.wikipedia.org/wiki/HTML "HTML") o [XML](https://es.wikipedia.org/wiki/XML "XML"). Como resultado de esto, es posible navegar de un recurso REST a muchos otros, simplemente siguiendo enlaces sin requerir el uso de registros u otra infraestructura adicional. # Recursos Un concepto importante en REST es la existencia de *recursos* (elementos de información), que pueden ser accedidos utilizando un identificador global (un [Identificador Uniforme de Recurso](https://es.wikipedia.org/wiki/URI "URI")). Para manipular estos recursos, los *componentes* de la red (clientes y servidores) se comunican a través de una interfaz estándar (HTTP) e intercambian *representaciones* de estos recursos (los ficheros que se descargan y se envían) - es cuestión de debate, no obstante, si la distinción entre *recursos* y sus *representaciones* es demasiado [platónica](https://es.wikipedia.org/wiki/Idealismo_plat%C3%B3nico "Idealismo platónico") para su uso práctico en la red, aunque es popular en la comunidad [RDF](https://es.wikipedia.org/wiki/Resource_Description_Framework "Resource Description Framework"). La petición puede ser transmitida por cualquier número de *conectores* (por ejemplo clientes, servidores, cachés, túneles, etc.) pero cada uno lo hace sin "ver más allá" de su propia petición (lo que se conoce como *stateless* ([sin estado](https://es.wikipedia.org/wiki/Protocolo_sin_estado "Protocolo sin estado")), otra restricción de REST, que es un principio común con muchas otras partes de la arquitectura de redes y de la información). Así, una aplicación puede interactuar con un recurso conociendo el identificador del recurso y la acción requerida, no necesitando conocer si existen cachés, [proxys](https://es.wikipedia.org/wiki/Servidor_proxy "Servidor proxy"), [cortafuegos](https://es.wikipedia.org/wiki/Cortafuegos_(inform%C3%A1tica) "Cortafuegos (informática)"), túneles o cualquier otra cosa entre ella y el servidor que guarda la información. La aplicación, sin embargo, debe comprender el formato de la información devuelta (la *representación*), que es por lo general un documento HTML o XML, aunque también puede ser una imagen o cualquier otro contenido. # Llamada a procedimiento remoto (RPC) En [computación distribuida](https://es.wikipedia.org/wiki/Computaci%C3%B3n_distribuida "Computación distribuida"), la llamada a procedimiento remoto (en [inglés](https://es.wikipedia.org/wiki/Idioma_ingl%C3%A9s "Idioma inglés"), *Remote Procedure Call*, RPC) es un programa que utiliza una computadora para ejecutar código en otra máquina remota sin tener que preocuparse por las comunicaciones entre ambas. El protocolo que se utiliza para esta llamada es un gran avance sobre los *[sockets](https://es.wikipedia.org/wiki/Socket_de_Internet "Socket de Internet")*[ de Internet](https://es.wikipedia.org/wiki/Socket_de_Internet "Socket de Internet") usados hasta el momento. De esta manera el programador no tenía que estar pendiente de las comunicaciones, estando estas encapsuladas dentro de las RPC. Las RPC son muy utilizadas dentro de la [comunicación](https://es.wikipedia.org/wiki/Comunicaci%C3%B3n "Comunicación") [cliente-servidor](https://es.wikipedia.org/wiki/Cliente-servidor "Cliente-servidor"). Siendo el cliente el que inicia el proceso solicitando al servidor que ejecute cierto procedimiento o función y enviando este de vuelta el resultado de dicha operación al cliente. # REST frente a RPC Una aplicación web REST requiere un enfoque de diseño diferente a una aplicación basada en RPC (llamada de procedimiento remoto). En RPC, se pone el énfasis en la diversidad de operaciones del protocolo, o verbos; por ejemplo una aplicación RPC podría definir operaciones como: getUser() addUser() removeUser() updateUser() getLocation() addLocation() removeLocation() updateLocation() listUsers() listLocations() findLocation() findUser() En REST, al contrario, el énfasis se pone en los recursos, o sustantivos; especialmente en los nombres que se le asigna a cada tipo de recurso. Por ejemplo, una aplicación REST podría definir algunos tipos de recursos asignándoles estos nombres: Usuario {} Localización {} Cada recurso tendría su propio identificador, como [http://www.example.org/locations/us/ny/new_york_city.](http://www.example.org/locations/us/ny/new_york_city.) Los clientes trabajarían con estos recursos a través de las operaciones estándar de HTTP, como GET para descargar una copia del recurso. Obsérvese cómo cada objeto tiene su propia URL y puede ser fácilmente cacheado, copiado y guardado como marcador. POST se utiliza por lo general para acciones con efectos laterales, como enviar una orden de compra o añadir ciertos datos a una colección. Por ejemplo, el registro para un usuario podría tener el siguiente aspecto: <usuario> <nombre>Maximiliano Alejandro</nombre> <sexo>hombre</sexo> <localización href="[http://www.example.org/locations/us/ny/new_york_city">Nueva](http://www.example.org/locations/us/ny/new_york_city%22%3ENueva) York, NY, US</localización> </usuario> Para actualizar la localización del usuario, un cliente REST podría primero descargar el registro XML anterior usando GET. El cliente después modificaría el fichero para cambiar la localización y lo subiría al servidor utilizando HTTP PUT. Nótese, sin embargo, que los verbos HTTP (POST, GET, PUT, DELETE) no proporcionan ningún mecanismo estándar para descubrir recursos -- no hay ninguna operación LIST o FIND en HTTP, que se corresponderían con las operaciones list\*() y find\*() en el ejemplo RPC. En su lugar, las aplicaciones basadas en datos REST resuelven el problema tratando una colección de resultados de búsqueda como otro tipo de recurso, lo que requiere que los diseñadores de la aplicación conozcan URLs adicionales para mostrar o buscar cada tipo de recurso. Por ejemplo, una petición GET HTTP sobre la URL [http://www.example.org/locations/us/ny/](http://www.example.org/locations/us/ny/) podría devolver un enlace a una lista de ficheros en XML con todas las localizaciones posibles en Nueva York, mientras que una petición GET a la URL [http://www.example.org/users?surname=Michaels](http://www.example.org/users?surname=Michaels) podría devolver una lista de enlaces a todos los usuarios con el apellido "Michaels". REST proporciona algunas indicaciones sobre cómo realizar este tipo de acciones como parte de su restricción "hipermedia como el medio de estado de la aplicación", lo que sugiere el uso de un lenguaje de formularios (tales como un formulario HTML) para especificar consultas parametrizadas. La iniciativa OpenSearch de A9.com intenta estandarizar las búsquedas usando REST estableciendo especificaciones para descubrir recursos y un formato genérico para utilizar con sistemas basados en REST, incluyendo el RDF, XTM, Atom, RSS (en sus varias formas) y XML con XLink para gestionar los enlaces. # Implementaciones públicas Dado que la definición de REST es muy amplia, es posible afirmar que existe un enorme número de aplicaciones REST en la red (prácticamente cualquier cosa accesible mediante una petición HTTP GET). De forma más restrictiva, en contraposición a los servicios web y el RPC, REST se puede encontrar en diferentes áreas de la web: * La [blogosfera](https://es.wikipedia.org/wiki/Blogosfera "Blogosfera") -el universo de los [blogs](https://es.wikipedia.org/wiki/Blog "Blog")- está, en su mayor parte, basado en REST, dado que implica descargar ficheros XML (en formato [RSS](https://es.wikipedia.org/wiki/RSS "RSS") o [Atom](https://es.wikipedia.org/wiki/Atom_(formato_de_redifusi%C3%B3n) "Atom (formato de redifusión)")) que contienen listas de enlaces a otros recursos. * [Amazon.com](https://es.wikipedia.org/wiki/Amazon.com "Amazon.com") ofrece su [interfaz para desarrolladores](https://www.amazon.com/gp/aws/landing.html) tanto en formato REST como en formato [SOAP](https://es.wikipedia.org/wiki/Simple_Object_Access_Protocol "Simple Object Access Protocol") (siendo la versión REST la que recibe mayor tráfico). * [eBay](https://es.wikipedia.org/wiki/EBay "EBay") ofreció hasta 2008 una interfaz REST [para desarrolladores](http://developer.ebay.com/rest/). * El Proyecto ["Seniors Canada On-line"](https://web.archive.org/web/20060428061214/http://www.seniors.gc.ca/index.jsp) del Gobierno de [Canadá](https://es.wikipedia.org/wiki/Canad%C3%A1 "Canadá") ofrece una interfaz REST [descrito aquí](http://www.megginson.com/blogs/quoderat/archives/2005/03/09/public-rest-application-seniors-canada-online/). * [Bloglines](https://es.wikipedia.org/wiki/Bloglines "Bloglines") ofrece una API basada en REST [para desarrolladores](https://web.archive.org/web/20051228212538/http://www.bloglines.com/services/). * [Yahoo!](https://es.wikipedia.org/wiki/Yahoo! "Yahoo!") ofrece una API en REST [para desarrolladores](http://developer.yahoo.com/). * El mecanismo de enrutamiento de [Ruby on Rails](https://es.wikipedia.org/wiki/Ruby_on_Rails "Ruby on Rails") soporta aplicaciones REST utilizando el [patrón de diseño](https://es.wikipedia.org/wiki/Patr%C3%B3n_de_dise%C3%B1o "Patrón de diseño") [MVC](https://es.wikipedia.org/wiki/Modelo_Vista_Controlador "Modelo Vista Controlador"). * [Microsoft](https://es.wikipedia.org/wiki/Microsoft "Microsoft") tiene su implementación en ADO.NET Data Services Framework (anteriormente conocido como “Astoria”) [\[1\]](http://msdn.microsoft.com/en-us/library/cc668792.aspx). * El mismo mecanismo en [Catalyst](http://www.catalystframework.org/) también soporta aplicaciones REST mediante [MVC](https://es.wikipedia.org/wiki/Modelo_Vista_Controlador "Modelo Vista Controlador"). * El publicador de objetos de [Zope](https://es.wikipedia.org/wiki/Zope "Zope"). * Implementación REST para Java: [RestLet](https://web.archive.org/web/20110515125242/http://www.restlet.org/). * Facebook ofrece una API basada en REST. * Twitter ofrece una API basada en REST. * MEGA ofrece una API basada en REST. * MercadoLibre ofrece una API basada en REST [para desarrolladores](http://developers.mercadolibre.com/). * [OpenNebula](https://es.wikipedia.org/wiki/Opennebula "Opennebula") por medio de formato [JSON](https://es.wikipedia.org/wiki/JSON "JSON") y REST, permite crear, controlar y monitorizar servicios entre máquinas virtuales interconectadas.[1](https://es.wikipedia.org/wiki/Transferencia_de_Estado_Representacional#cite_note-1)? Probablemente existan muchas otras implementaciones similares. En cualquier caso debe tenerse en cuenta que muchas de las implementaciones descritas arriba, no son totalmente RESTful, esto es, no respetan todas las restricciones que impone la arquitectura REST. Sin embargo todas están inspiradas en REST y respetan los aspectos más significativos y restrictivos de su arquitectura, en particular la restricción de "interfaz uniforme". Estos servicios han sido denominados ["Accidentalmente RESTful"](http://www.markbaker.ca/2002/09/Blog/2005/04/14#2005-04-amazon-next). # Enlaces de interés Que es una API REST y para que sirve, geekytehory, [https://geekytheory.com/que-es-una-api-rest-y-para-que-se-utiliza](https://geekytheory.com/que-es-una-api-rest-y-para-que-se-utiliza) Servicios Web: RESTful, Bigeek, [https://blog.bi-geek.com/servicios-web-restful/](https://blog.bi-geek.com/servicios-web-restful/) Transferencia de Estado Representacional (REST), Wikipedia, [https://es.wikipedia.org/wiki/Transferencia_de_Estado_Representacional](https://es.wikipedia.org/wiki/Transferencia_de_Estado_Representacional) Hipermedia, Wikipedia, [https://es.wikipedia.org/wiki/Hipermedia](https://es.wikipedia.org/wiki/Hipermedia) Llamada a procedimiento remoto, Wikipedia, [https://es.wikipedia.org/wiki/Llamada_a_procedimiento_remoto](https://es.wikipedia.org/wiki/Llamada_a_procedimiento_remoto) Computación distribuida, Wikipedia, [https://es.wikipedia.org/wiki/Computaci%C3%B3n_distribuida](https://es.wikipedia.org/wiki/Computaci%C3%B3n_distribuida) Guía para utilizar la API de Twitter Search, programacion.net, [https://programacion.net/articulo/guia_para_utilizar_la_api_de_twitter_search_1652](https://programacion.net/articulo/guia_para_utilizar_la_api_de_twitter_search_1652)