La mejor manera de construir los servicios web en REST

Original article: http://www.xfront.com/REST-Web-Services.html

Roger L. Costello
Primero voy a dar una breve introducción a REST y luego describiré cómo construir servicios Web en el estilo REST.

¿Qué es REST?
REST es un término determinado por Roy Fielding en su Ph.D. tesis [1] para describir un estilo de arquitectura de sistemas en red. REST es un acrónimo de Representational State Transfer.

¿Por qué se llama Representational State Transfer?
La Web se compone de los recursos. Un recurso es cualquier elemento de interés. Por ejemplo, el Boeing Aircraft Corp puede definir un recurso 747. Los clientes pueden acceder a ese recurso con esta URL:
http://www.boeing.com/aircraft/747
Se devuelve una representación del recurso (por ejemplo, Boeing747.html). La representación coloca la aplicación de cliente en un estado. El resultado del cliente que atraviesa un hipervínculo en Boeing747.html se accede a un otro recurso. La nueva representación coloca la aplicación de cliente en un otro estado. Así, los cambios (las transferencias) de la aplicación de cliente establece con cada representación de los recursos -> Y así, pues, se llama Transferencia de estado representacional!
Aquí está la explicación de Roy Fielding del significado de Transferencia de estado representacional:
"Transferencia de estado representacional pretende evocar una imagen de cómo se comporta una aplicación web bien diseñada: una red de páginas web (un estado de la máquina virtual), donde el usuario avanza a través de una aplicación mediante la selección de enlaces (las transiciones de estado), lo que resulta en la página siguiente (lo que representa el siguiente estado de la solicitud) después de haber transferido al usuario y procesa para su uso".

La motivación para REST
La motivación para REST constituía en capturar las características de la Web que hizo la Web tener éxito. Posteriormente estas características se utilizan para guiar la evolución de la Web.

REST – es un estilo arquitectónico y no es un estándar
REST no es el estándar. Usted no podrá ver el W3C extinción de una especificación REST. Usted no verá IBM o Microsoft o Sun vendiendo la caja de herramientas de desarrollador de REST. ¿Por qué? Porque REST es sólo un estilo arquitectónico. No se puede reprimir ese estilo. Sólo se puede entender, y diseñar sus servicios web en ese estilo. (Es una análoga a la arquitectura cliente-servidor. No hay un estándar cliente-servidor.)
Como REST no es el estándar, de verdad utiliza los estánderes:
HTTP
URL
XML / HTML / GIF / JPEG / etc (Representaciones de los recursos)
text / xml, text / html, image / gif, image / jpeg, etc (los tipos de MIME)

El Sistema REST Clásico
¡La Web es un sistema REST! Muchos servicios Web que usted ha estado utilizando estos años tales como servicios de pedir los libros, servicios de búsqueda, los servicios de diccionario, online etc – estos son servicios web basados en REST. ¡Ay, estaba usando REST, la construcción de servicios REST y ni siquiera lo sabía.
REST tiene que ver con el "cuadro grande" de la Web. No tiene los detalles de implementación (por ejemplo, el uso de servlets de Java o CGI para implementar un servicio Web). Así que vamos a ver un ejemplo de la creación de un servicio Web desde el "cuadro grande" de la perspectiva REST.

Almacén de repuestos de servicios Web
Parts Depot, Inc (es una empresa ficticia) ha desplegado algunos servicios web para permitir a sus clientes:
• obtener una lista de repuestos
• obtener información detallada acerca de una parte particular
• presentar una orden de la compra (PO)
Vamos a considerar cómo cada uno de estos servicios se implementan de manera REST.

Obtener la lista de repuestos
El servicio web pone a disposición una dirección URL a un recurso de la lista de repuestos. Por ejemplo, un cliente podría utilizar esta URL para obtener la lista de los repuestos:
http://www.parts-depot.com/parts
Tenga en cuenta que "cómo" el servicio web genera la lista de los repuestos es completamente transparente para el cliente. Todo lo que sabe el cliente es que si él / ella se somete la URL anterior, entonces, se devuelve un documento que contiene la lista de repuestos. Como la implementación es transparente para los clientes, Piezas Depot es libre de modificar la ejecución de este recurso sin afectar a los clientes. Esta es la articulación flexible.
Aquí está el documento que el cliente recibe:

<?xml version="1.0"?>
<p:Parts xmlns:p="http://www.parts-depot.com" 
         xmlns:xlink="http://www.w3.org/1999/xlink">
      <Part id="00345" xlink:href="http://www.parts-depot.com/parts/00345"/>
      <Part id="00346" xlink:href="http://www.parts-depot.com/parts/00346"/>
      <Part id="00347" xlink:href="http://www.parts-depot.com/parts/00347"/>
      <Part id="00348" xlink:href="http://www.parts-depot.com/parts/00348"/>
</p:Parts>
[Supongamos que a través de la negociación de contenido el servicio ha determinado que el cliente quiere la representación como XML (para el procesamiento de máquina a máquina).] Tenga en cuenta que la lista de repuestos tiene los enlaces para obtener la información detallada sobre cada repuesto. Esta es una característica principal de REST. El cliente transmite de un estado al siguiente mediante el control y la elección entre las direcciones URL alternativas en el documento de respuesta.

Obtener información detallada acerca de una parte particular
El servicio web pone a disposición una dirección URL para cada recurso parcial. Por ejemplo, eso es la manera como un cliente solicita parte 00345:
http://www.parts-depot.com/parts/00345
Aquí está el documento que el cliente recibe:
<?xml version="1.0"?>
<p:Part xmlns:p="http://www.parts-depot.com"   
        xmlns:xlink="http://www.w3.org/1999/xlink">
      <Part-ID>00345</Part-ID>
      <Name>Widget-A</Name>
      <Description>This part is used within the frap assembly</Description>
      <Specification xlink:href="http://www.parts-depot.com/parts/00345/specification"/>
      <UnitCost currency="USD">0.10</UnitCost>
      <Quantity>10</Quantity>
</p:Part>
Observe una vez más cómo estos datos se vincula con aún más datos cuya especificación para esta parte se puede encontrar por la que atraviesa el hipervínculo. Cada documento de respuesta permite al cliente profundizar para obtener información más detallada.

Presentar PO
El servicio web pone a disposición una dirección URL para enviar un PO. El cliente crea un documento de instancia PO que se ajusta al esquema PO que ha diselado la empresa Parts Depot (y ha publicado en un documento WSDL). El cliente envía po.xml como la carga útil de un HTTP POST.
El servicio PO responde al HTTP POST con una URL a PO presentado antes. De este modo, el cliente puede recuperar el PO en cualquier momento posterior (para actualizarlo / editarlo). El PO ha convertido en un repuesto de información que se comparte entre el cliente y el servidor. La información compartida (PO) se da una dirección (URL) por el servidor y se expone como un servicio Web.

Las URL lógicas contra las URL Físicas
Un recurso es una entidad conceptual. Una representación es una manifestación concreta del recurso. Esta URL:
http://www.parts-depot.com/parts/00345
es una URL lógica y no física. Por lo tanto, hay no necesita, por ejemplo, una página HTML estática para cada parte. De hecho, si hubiera un millón de repuestos, entonces un millón de páginas HTML estáticas no tendrían un diseño tan atractivo.
[Los detalles de implementación: Parts Depot podría implementar el servicio que recibe datos detallados sobre una parte particular a través de emplear un servlet de Java que analiza string después de host name, utiliza el número de repuesto para consultar la base de datos de los repuestos, la formulación de los resultados de la consulta como XML, y a continuación, devolver el XML como la carga útil de la respuesta HTTP.]
En realidad, el estilo de URL no debe revelar la técnica de aplicación utilizada. Usted necesita tener la libertad de cambiar la aplicación sin afectar los clientes o tener direcciones de URL engañosas.

Las características de los servicios web
Aquí están las características de REST:
• Cliente-Servidor: un estilo de interacción basado en la tracción: los componentes bajo elconsumo arrancan las representaciones.
• Apártidas: cada solicitud del cliente al servidor debe contener toda la información necesaria para comprender la solicitud, y no se puede tomar ventaja de cualquier contexto almacenado en el servidor.
• Caché: para mejorar la eficiencia red las respuestas deben ser capaces de ser etiquetado como cacheable o no almacenable en caché.
• Interfaz uniforme: se accede a todos los recursos con una interfaz genérica (por ejemplo, HTTP GET, POST, PUT, DELETE).
• Recursos con nombre - el sistema se compone de los recursos que se nombran mediante una dirección URL.
• Representaciones de recursos interconectados son las representaciones de los recursos qu se interconectan utilizando direcciones URL, lo que permite a un cliente pasar de un estado a otro.
• Componentes en capas son los intermediarios, tales como servidores proxy, servidores de caché, pasarelas, etc., se pueden insertar entre los clientes y los recursos para apoyar el desempeño, la seguridad, etc.

Los principios para el diseño de los servicios web de REST
1. La clave para crear los servicios web en una red de REST (es decir, la Web) se base en identificación de todas las entidades conceptuales que desee exponerlos como servicios. Más abajo hemos visto algunos ejemplos de recursos: lista de repuestos, repuestos de datos detallados, orden de compra.

2. Cree una URL para cada recurso. Los recursos deben ser sustantivos, no los verbos. Por ejemplo, no utilice este:
http://www.parts-depot.com/parts/getPart?id=00345
Nota el verbo, getPart. En su lugar, utilice un sustantivo:
http://www.parts-depot.com/parts/00345

3. Clasifique sus recursos según si los clientes solo pueden recibir una representación del recurso, o si los clientes pueden modificar (añadir a) el recurso. En primer caso, haga los recursos ser accesibles mediante HTTP GET. Para la segunda, haga esos recursos ser accesibles mediante HTTP POST, PUT, y / o DELETE.

4. Todos los recursos accesibles a través de HTTP GET deben ser libres de efectos secundarios. Es decir, los recursos simplemente deben devolver una representación del recurso. Invocando el recurso no debe dar lugar a la modificación del recurso.

5. Ningún hombre / mujer es una isla. Del mismo modo, ninguna representación debe ser una isla. En otras palabras, ponga los hipervínculos dentro de las representaciones de recursos para permitir a los clientes profundizar para obtener más información y / o para obtener información relacionada.

6. Diseñe para revelar los datos gradualmente. No revele todo en un documento de respuesta única. Proporcione los enlaces para obtener más detalles.

7. Especifique el formato de datos de respuesta utilizando un esquema (DTD, esquema del W3C, RelaxNG o Schematron). Para los servicios que requieren un POST o PUT, también debe proporcionar un esquema para especificar el formato de la respuesta.

8. Describa cómo sus servicios se invocarán usando un documento WSDL o simplemente un documento HTML.

Resumen
En este artículo se describe REST como un estilo arquitectónico. De hecho, es el estilo arquitectónico de la Web. REST describe lo que hace el funcionamiento de web mejor. La adhesión a los principios REST hará sus servicios funcionar bien en el contexto de la Web.
En un próximo artículo voy a escribir sobre la evolución de la Web utilizando los principios de REST.

Reconocimiento
Gracias a Robert Leftwich y Philip Eskelin por sus comentarios muy útiles en la creación de este documento.

Referencias
[1] http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

Home | SEO Words | Coloring