REST - Historial de revisiones

Javiermartin jc: Texto reemplazado: «
» por «»

2019-07-06T20:44:25Z

Texto reemplazado: «<div align="justify">» por «»

Sasousuke: /* Ventajas */

2012-09-27T17:48:32Z

‎Ventajas

Yaguajay3 jc en 16:03 4 ene 2011

2011-01-04T16:03:43Z

Yaguajay3 jc en 16:02 4 ene 2011

2011-01-04T16:02:46Z

Lanyin jc.stgo en 20:05 23 nov 2010

2010-11-23T20:05:16Z

Alina idict en 18:45 27 oct 2010

2010-10-27T18:45:10Z

Arielv infomed en 19:53 13 oct 2010

2010-10-13T19:53:08Z

Arielv infomed en 19:50 13 oct 2010

2010-10-13T19:50:20Z

Arielv infomed: Página creada con 'REST (acrónimo REpresentational State Transfer) es una manera de construir una aplicación para los sistemas distribuidos como la World Wide Web. El término fue acuñado por R...'

2010-10-13T19:48:25Z

Página creada con 'REST (acrónimo REpresentational State Transfer) es una manera de construir una aplicación para los sistemas distribuidos como la World Wide Web. El término fue acuñado por R...'

Página nueva

REST (acrónimo REpresentational State Transfer) es una manera de construir una aplicación para los sistemas distribuidos como la World Wide Web. El término fue acuñado por Roy Fielding en el 2000.

REST no es un protocolo ni un formato, es más bien un estilo de arquitectura, mimetiza el estilo de arquitectura original de la Web.

Dentro de esta arquitectura, un componente lee o modifica un recurso utilizando una representación e un de dicho recurso. Un recurso es una cosa nombrable, que puede cambiar con el tiempo. Una representación es una secuencia de octetos, eventualmente acompañada de metadatos(secuencia de nombre/valor). Un componente es un actor, y está conectado a otros componentes y recursos a través de canales que permiten la interacción sin estado.

La aplicación de esta arquitectura en la Web se basa en algunos principios simples:

* La URI es importante: conocer la URI debe ser suficiente para nombrar e identificar un recurso
* HTTP provee de todas las operaciones escenciales para manejar recursos (GET, POST, PUT, y DELETE).
* Cada operación es independiente: no hay estado.
* Utilización de estándares: son a menudo utilizados HTML o XML ya que permiten la comunicación con otros recursos y aseguran así la navegación dentro de la aplicación REST.

== Descripción de REST ==

Éste estilo arquitectural no está limitado al desarrollo de aplicaciones para el uso directo por personas. Actualmente se está utilizando más y más en el desarrollo de [[SOA | arquitecturas orientadas a servicios]] utilizando servicios Web destinados a la comunicación entre máquinas. Rest supone una alternativa al estilo arquitectural RPC.

Las respuestas de los requests a diferencia de SOAP y XML-RPC no han de ser obligatoriamente XML. Las respuestas en formato JSON u objetos de Java Serializados son perfectamente aceptables.

== Ventajas ==

La tésis de Roy Fielding relaciona las muchas ventajas con respecto a los otros estilos de arquitectura de aplicaciones web. Entre otras citamos:

* La aplicación es más simple de mantener, los vínculos son más estructurados y su forma es más común. Es también mas común que los vínculos sean el modo de llevar el estado de una aplicación Web.
* A ausencia de gestión de estado de cliente en el servidor conduce un consumo más eficiente de la memoria, una mayor simplificación de la funcionalidad y una capacidad más grande de gestionar un grán número de requests al mismo tiempo.
* La ausencia de la gestión de estado del cliente en el servidor permite implementar un balance de carga más simple: una sesión del cliente no tiene que ser mantenida por un servidor en particular, ni propagada a otros servidores. Ésta permite también una mejor evolución y tolerancia a fallos.
* La utilización de protocolo HTTP y todas las partes de sus encabezamientos(la mayor parte de la gramática HTTP)
* El uso de la UCI como representación de un recurso permite la existencia de servidores caché.

== Inconvenientes ==

El envío de datos de un formulario HTML usando un método como DELETE no está comprendida en todos los navegadores. Para aliviar este problema se emula el comportamiento usando POST.

== Software ==

* Python : RIP
* Django : Piston
* Ruby On Rails : Rails
* Java : Restlet
* Java : especificación de RESTful web services para Java (JAX-RS) JSR311
* Java : jersey, implementación de referencia de JSR311
* Java : Jboss RESTEasy
* PHP : Symfony
* .NET 3.5 : ADO.NET Data Services : (ex-Astoria)

== Fuentes ==

* [http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm (en) Tesis de Roy Fielding]
* [http://www.eweek.com/c/a/Application-Development/JBoss-Helps-Developers-RESTEasy-Writing-RESTbased-Java-Web-Services/ (en) JBoss Helps Developers RESTEasy Writing REST-based Java Web Services]
* [http://www.w3.org/TR/2004/REC-webarch-20041215/#id-resources (en) Relación URI recurso]

[[Category:Informática]]

@@ Línea 4: / Línea 4: @@
 |tamaño=
 |concepto=REST no es un protocolo ni un formato, es más bien un estilo de arquitectura, mimetiza el estilo de arquitectura original de la Web.
-}}<div align="justify">
+}}
 '''REST''', (acrónimo '''RE'''presentational '''S'''tate '''T'''ransfer) es una arquitectura de [[Servicio Web|servicios Web]], para sistemas distribuidos como la World Wide Web. El término fue acuñado por Roy Fielding en el 2000.

@@ Línea 33: / Línea 33: @@
 *A ausencia de gestión de estado de cliente en el servidor conduce un consumo más eficiente de la memoria, una mayor simplificación de la funcionalidad y una capacidad más grande de gestionar un grán número de requests al mismo tiempo.
 *La ausencia de la gestión de estado del cliente en el servidor permite implementar un balance de carga más simple: una sesión del cliente no tiene que ser mantenida por un servidor en particular, ni propagada a otros servidores. Ésta permite también una mejor evolución y tolerancia a fallos.
-*La utilización de protocolo HTTP y todas las partes de sus encabezamientos(la mayor parte de la gramática HTTP)
+*La utilización de protocolo HTTP y todas las partes de sus encabezamientos(la mayor parte de la gramática HTTP).
 === Inconvenientes  ===
 El envío de datos de un formulario HTML usando un método como DELETE no está comprendida en todos los navegadores. Para aliviar este problema se emula el comportamiento usando POST.
 == Software  ==

@@ Línea 1: / Línea 1: @@
-{Definición
+{{Definición
 |nombre=REST
 |imagen=Imagen_de_rest.JPG

@@ Línea 1: / Línea 1: @@
-{{Normalizar}}
+{Definición
+|nombre=REST
 '''REST''', (acrónimo '''RE'''presentational '''S'''tate '''T'''ransfer) es una arquitectura de [[Servicio Web|servicios Web]], para sistemas distribuidos como la World Wide Web. El término fue acuñado por Roy Fielding en el 2000.

@@ Línea 1: / Línea 1: @@
-{{Mejorar}}{{Normalizar}}
+{{Normalizar}}
 '''REST''' (acrónimo '''RE'''presentational '''S'''tate '''T'''ransfer) es una arquitectura de [[Servicio Web|servicios Web]], para sistemas distribuidos como la World Wide Web. El término fue acuñado por Roy Fielding en el 2000.
 REST no es un protocolo ni un formato, es más bien un estilo de arquitectura, mimetiza el estilo de arquitectura original de la Web.
@@ Línea 31: / Línea 32: @@
 *El uso de la UCI como representación de un recurso permite la existencia de servidores caché.
-== Inconvenientes  ==
+=== Inconvenientes  ===
 El envío de datos de un formulario HTML usando un método como DELETE no está comprendida en todos los navegadores. Para aliviar este problema se emula el comportamiento usando POST.

@@ Línea 1: / Línea 1: @@
-'''REST''' (acrónimo '''RE'''presentational '''S'''tate '''T'''ransfer) es una arquitectura de [[Servicio Web | servicios Web]], para sistemas distribuidos como la World Wide Web. El término fue acuñado por Roy Fielding en el 2000.
+{{Mejorar}}{{Normalizar}}
 REST no es un protocolo ni un formato, es más bien un estilo de arquitectura, mimetiza el estilo de arquitectura original de la Web.
-== Conceptos ==
+== Conceptos  ==
 Dentro de esta arquitectura, un componente lee o modifica un recurso utilizando una representación e un de dicho recurso. Un recurso es una cosa nombrable, que puede cambiar con el tiempo. Una representación es una secuencia de octetos(bytes), eventualmente acompañada de metadatos(secuencia de nombre/valor). Un componente es un actor, y está conectado a otros componentes y recursos a través de canales que permiten la interacción sin estado.
 La aplicación de esta arquitectura en la Web se basa en algunos principios simples:
-* La [[URI]] es importante: conocer la URI debe ser suficiente para nombrar e identificar un recurso
+*La [[URI]] es importante: conocer la URI debe ser suficiente para nombrar e identificar un recurso
-* [[HTTP]] provee de todas las operaciones escenciales para manejar recursos (GET, POST, PUT, y DELETE).
+*[[HTTP]] provee de todas las operaciones escenciales para manejar recursos (GET, POST, PUT, y DELETE).
-* Cada operación es independiente: no hay estado.
+*Cada operación es independiente: no hay estado.
-* Utilización de estándares: son a menudo utilizados [[HTML]] o [[XML]] ya que permiten la comunicación con otros recursos y aseguran así la navegación dentro de la aplicación REST.
+*Utilización de estándares: son a menudo utilizados [[HTML]] o [[XML]] ya que permiten la comunicación con otros recursos y aseguran así la navegación dentro de la aplicación REST.
-== Descripción de REST ==
+== Descripción de REST  ==
-Éste estilo arquitectural no está limitado al desarrollo de aplicaciones para el uso directo por personas. Actualmente se está utilizando más y más en el desarrollo de [[SOA | arquitecturas orientadas a servicios]] utilizando servicios Web destinados a la comunicación entre máquinas. Rest supone una alternativa al estilo arquitectural RPC.
+Éste estilo arquitectural no está limitado al desarrollo de aplicaciones para el uso directo por personas. Actualmente se está utilizando más y más en el desarrollo de [[SOA|arquitecturas orientadas a servicios]] utilizando servicios Web destinados a la comunicación entre máquinas. Rest supone una alternativa al estilo arquitectural RPC.
 Las respuestas de los requests a diferencia de [[SOAP]] y XML-RPC no han de ser obligatoriamente XML. Las respuestas en formato JSON u objetos de Java Serializados son perfectamente aceptables.
-== Ventajas ==
+== Ventajas  ==
 La tésis de Roy Fielding relaciona las muchas ventajas con respecto a los otros estilos de arquitectura de aplicaciones web. Entre otras citamos:
-* La aplicación es más simple de mantener, los vínculos son más estructurados y su forma es más común. Es también mas común que los vínculos sean el modo de llevar el estado de una aplicación Web.
+*La aplicación es más simple de mantener, los vínculos son más estructurados y su forma es más común. Es también mas común que los vínculos sean el modo de llevar el estado de una aplicación Web.
-* A ausencia de gestión de estado de cliente en el servidor conduce un consumo más eficiente de la memoria, una mayor simplificación de la funcionalidad y una capacidad más grande de gestionar  un grán número de requests al mismo tiempo.
+*A ausencia de gestión de estado de cliente en el servidor conduce un consumo más eficiente de la memoria, una mayor simplificación de la funcionalidad y una capacidad más grande de gestionar un grán número de requests al mismo tiempo.
-* La ausencia de la gestión de estado del cliente en el servidor permite implementar un balance de carga más simple: una sesión del cliente no tiene que ser mantenida por un servidor en particular, ni propagada a otros servidores. Ésta permite también una mejor evolución y tolerancia a fallos.
+*La ausencia de la gestión de estado del cliente en el servidor permite implementar un balance de carga más simple: una sesión del cliente no tiene que ser mantenida por un servidor en particular, ni propagada a otros servidores. Ésta permite también una mejor evolución y tolerancia a fallos.
-* La utilización de protocolo HTTP y todas las partes de sus encabezamientos(la mayor parte de la gramática HTTP)
+*La utilización de protocolo HTTP y todas las partes de sus encabezamientos(la mayor parte de la gramática HTTP)
-* El uso de la UCI como representación de un recurso permite la existencia de servidores caché.
+*El uso de la UCI como representación de un recurso permite la existencia de servidores caché.
-== Inconvenientes ==
+== Inconvenientes  ==
 El envío de datos de un formulario HTML usando un método como DELETE no está comprendida en todos los navegadores. Para aliviar este problema se emula el comportamiento usando POST.
-== Software ==
+== Software  ==
-* Python : RIP
+*Python&nbsp;: RIP
-* Django : Piston
+*Django&nbsp;: Piston
-* Ruby On Rails : Rails
+*Ruby On Rails&nbsp;: Rails
-* Java : Restlet
+*Java&nbsp;: Restlet
-* Java : especificación de RESTful web services para Java (JAX-RS) JSR311
+*Java&nbsp;: especificación de RESTful web services para Java (JAX-RS) JSR311
-* Java : jersey, implementación de referencia de JSR311
+*Java&nbsp;: jersey, implementación de referencia de JSR311
-* Java : Jboss RESTEasy
+*Java&nbsp;: Jboss RESTEasy
-* PHP : Symfony
+*PHP&nbsp;: Symfony
-* .NET 3.5 : ADO.NET Data Services : (ex-Astoria)
+*.NET 3.5&nbsp;: ADO.NET Data Services&nbsp;: (ex-Astoria)
-== Fuentes ==
+== Fuentes  ==
-* [http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm (en) Tesis de Roy Fielding]
+*[http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm (en) Tesis de Roy Fielding]
-* [http://www.eweek.com/c/a/Application-Development/JBoss-Helps-Developers-RESTEasy-Writing-RESTbased-Java-Web-Services/ (en) JBoss Helps Developers RESTEasy Writing REST-based Java Web Services]
+*[http://www.eweek.com/c/a/Application-Development/JBoss-Helps-Developers-RESTEasy-Writing-RESTbased-Java-Web-Services/ (en) JBoss Helps Developers RESTEasy Writing REST-based Java Web Services]
-* [http://www.w3.org/TR/2004/REC-webarch-20041215/#id-resources (en) Relación URI recurso]
+*[http://www.w3.org/TR/2004/REC-webarch-20041215/#id-resources (en) Relación URI recurso]
 [[Category:Informática]]

@@ Línea 1: / Línea 1: @@
-REST (acrónimo REpresentational State Transfer) es una manera de construir una aplicación para los sistemas distribuidos como la World Wide Web. El término fue acuñado por Roy Fielding en el 2000.
+'''REST''' (acrónimo '''RE'''presentational '''S'''tate '''T'''ransfer) es una manera de construir una aplicación para los sistemas distribuidos como la World Wide Web. El término fue acuñado por Roy Fielding en el 2000.
 REST no es un protocolo ni un formato, es más bien un estilo de arquitectura, mimetiza el estilo de arquitectura original de la Web.
 Dentro de esta arquitectura, un componente lee o modifica un recurso utilizando una representación e un de dicho recurso. Un recurso es una cosa nombrable, que puede cambiar con el tiempo. Una representación es una secuencia de octetos, eventualmente acompañada de metadatos(secuencia de nombre/valor). Un componente es un actor, y está conectado a otros componentes y recursos a través de canales que permiten la interacción sin estado.