Está en la página 1de 10

Servicios Web de RESTful: Los aspectos básicos

Alex Rodriguez 09-2-2015


(最初于 06-11-2008)

Representational State Transfer (REST) ha obtenido una aceptación generalizada a lo largo de la


Web como una alternativa más sencilla que SOAP, y que los servicios Web basados en Web Services
Description Language (WSDL). La principal evidencia de este cambio en el diseño de interfaces es
la adopción de REST por los principales proveedores de servicios Web 2.0, —entre ellos Yahoo,
Google y Facebook— quienes han declarado obsoletas o han dejado de usar las interfaces basadas
en SOAP y WSDL, para exponer sus servicios utilizando un modelo más fácil de usar y orientado a
recursos. En este artículo, Alex Rodriguez le presenta los principios básicos de REST.

REST define un conjunto de principios arquitectónicos por los que se pueden diseñar servicios Web
que se centran en los recursos de un sistema, lo que incluye la forma en que los estados de los
recursos se dirigen y transfieren a través de HTTP por un amplio rango de clientes que están escritos
en diferentes lenguajes. Si lo medimos por el número de servicios Web que lo utilizan, en los últimos
años REST ha emergido como un modelo de diseño predominante para los servicios Web. De hecho,
REST ha tenido tanto impacto en la Web que ha desplazado enormemente al diseño de interfaces
basado en SOAP y WSDL, porque es un estilo considerablemente más fácil de utilizar.

REST no obtuvo mucha atención la primera vez que fue presentado en el 2000 por Roy Fielding en la
Universidad de California, Irvine, en su disertación académica, "Architectural Styles and the Design
of Network-based Software Architectures", que analiza un conjunto de principios arquitectónicos
de software que utilizan la Web como una plataforma para la computación distribuida. Ahora, años
después de su presentación, han empezado aparecer las principales infraestructuras para REST, y se
están desarrollando otras porque, por ejemplo, se ha anunciado que se va a convertir en una parte
integral de Java™ 6 en JSR-311.

Este artículo sugiere que, en su forma actual más pura, cuando atrae toda esta atención, las
implementaciones concretas siguen cuatro principios básicos de diseño de servicios Web de REST:

•  Utilice métodos HTTP de forma explícita.


•  Sea sin estados.
•  Exponga los URIS como estructuras de directorios.
•  Transfiera XML, JavaScript Object Notation (JSON), o ambos.
Las siguientes secciones amplían esos cuatro principios y proponen una razón técnica de por qué
deberían ser importantes para los diseñadores de servicios Web de REST.

© 版权所有 IBM 公司 2008, 2015 商标
Servicios Web de RESTful: Los aspectos básicos 第 1 页,共 10
developerWorks® ibm.com/developerWorks/cn/

Utilice métodos HTTP de forma explícita


Una de las principales características de un servicio Web de RESTful es el uso explícito de métodos
HTTP de una forma que siga el protocolo tal como está definido por RFC 2616. HTTP GET, por ejemplo,
se define como un método para producir datos, que está destinado a ser usado por una aplicación
del cliente para recuperar un recurso, para traer datos desde un servidor Web o para ejecutar una
consulta con la expectativa de que el servidor Web la busque y responda con un conjunto de recursos
que coincidan.

REST pide a los desarrolladores que utilicen HTTP de forma explícita y de una forma que sea coherente
con la definición del protocolo. Este principio básico del diseño de REST establece una correlación
individual entre las operaciones de crear, leer, actualizar y borrar (CRUD) y los métodos HTTP. Según
esta correlación:

•  Para crear un recurso en el servidor hay que utilizar un POST.


•  Para recuperar un recurso hay que utilizar un GET.
•  Para cambiar el estado de un recurso, o para actualizarlo, hay que utilizar un PUT.
•  Para eliminar o borrar un recurso hay que utilizar un DELETE.

Una desafortunada falla de diseño inherente de muchas APIs Web es la utilización de métodos HTTP
para fines no deseados. Por ejemplo, el URI de la solicitud en una solicitud HTTP GET, normalmente
identifica un recurso específico. O la cadena de caracteres de una consulta de un URI de la solicitud
incluye un conjunto de parámetros que define los criterios de búsqueda que el servidor utiliza para
encontrar un conjunto de recursos que coinciden. Al menos, así es cómo HTTP/1.1 RFC describe el
GET. Pero, hay muchos casos de APIs Web no atractivas que utilizan HTTP GET para desencadenar algo
transaccional en el servidor—por ejemplo, para añadir registros a una base de datos. En esos casos,
GET para solicitar el URI no se usa adecuadamente, al menos, no se usa de la forma RESTful. Si la API
Web utiliza GET para invocar procedimientos remotos, se parecerá a esto:
GET /adduser?name=Robert HTTP/1.1

No es un diseño muy atractivo, porque el método Web anterior soporta una operación de cambio
de estado sobre HTTP GET. Por ponerlo de otra manera, la solicitud HTTP GET anterior tiene efectos
colaterales. Si se procesa correctamente, el resultado de la solicitud será añadir un usuario nuevo—
en este ejemplo, Robert—para el almacén de datos subyacente. El problema aquí es principalmente
semántico. Los servidores Web están diseñados para responder a las solicitudes HTTP GET recuperando
los recursos que coinciden con la ruta (o los criterios de la consulta) del URI de la solicitud, y
devuelven los mismos, o una representación de ellos, en una respuesta; no para añadir un registro
a una base de datos. Utilizar GET de esta manera es inconsistente desde el punto de vista del uso
previsto del método del protocolo, y desde el punto de vista de los servidores Web conformes con
HTTP/1.1.

Más allá de la semántica, el otro problema con GET es que, para desencadenar el borrado,
modificación o incorporación de un registro en una base de datos, o para cambiar el estado por el
lado del servidor de alguna forma, invita a herramientas para capturar las memorias caché de la Web
(crawlers) y a motores de búsqueda para hacer cambios por el lado del servidor sin ninguna intención,
solo rastreando un enlace. Una forma sencilla de superar este problema habitual es mover a etiquetas

Servicios Web de RESTful: Los aspectos básicos 第 2 页,共 10


ibm.com/developerWorks/cn/ developerWorks®

XML los nombres y los valores de los parámetros del URI de la solicitud. Las etiquetas resultantes, una
representación XML de la entidad a crear, se pueden enviar en el cuerpo de una HTTP POST cuyo URI
de la solicitud es el objeto primario de la entidad (vea los Listados 1 y 2).

清单 1. Antes
GET /adduser?name=Robert HTTP/1.1

清单 2. Después
POST /users HTTP/1.1
Host: myserver
Content-Type: application/xml
<?xml version="1.0"?>
<user>
<name>Robert</name>
</user>

El método anterior es un ejemplo de una solicitud RESTful: uso adecuado de HTTP POST e inclusión
de la carga útil en el cuerpo de la solicitud. En la parte receptora, la solicitud se puede procesar
añadiendo el recurso que está contenido en el cuerpo como un subordinado del recurso que está
identificado en el URI de la solicitud; en este caso, el recurso nuevo se debería añadir como objeto
secundario de /users. Esta relación de contención entre la entidad nueva y su objeto primario, como
se especifica en la solicitud POST, es análoga a la forma en la que un archivo es subordinado a su
directorio primario. El cliente establece la relación entre la entidad y su objeto primario, y define el
URI de la nueva entidad en la solicitud POST.

Posteriormente, una aplicación del cliente podrá obtener una representación del recurso utilizando
el nuevo URI, observando que el recurso está ubicado, al menos lógicamente, bajo /users, como se
muestra en el Listado 3.

清单 3. Solicitud HTTP GET


GET /users/Robert HTTP/1.1
Host: myserver
Accept: application/xml

La utilización de GET de esta forma es explícita, porque GET sólo se utiliza para la recuperación
de datos. GET es una operación que no debería tener efectos colaterales, una propiedad también
conocida como idempotence.

En los casos en los que una operación de actualización sea soportada a través de HTTP GET, también se
deberá aplicar una refactorización similar de un método web, tal como se muestra en el Listado 4.

清单 4. Actualización sobre HTTP GET


GET /updateuser?name=Robert&newname=Bob HTTP/1.1

Esto cambia el atributo (o propiedad) name del recurso. Aunque, para dicha operación se puede
utilizar una cadena de consulta, y el Listado 4 es una operación operación simple, este patrón cadena-
de-consulta-como-método-de-firma tiende a estropearse cuando se utiliza para operaciones más
complejas. Ya que su meta es utilizar los métodos HTTP de forma explícita, un enfoque más RESTful es

Servicios Web de RESTful: Los aspectos básicos 第 3 页,共 10


developerWorks® ibm.com/developerWorks/cn/

enviar una solicitud HTTP PUT para actualizar el recurso, en vez de HTTP GET, por las mismas razones
anteriores (vea el Listado 5).

清单 5. Solicitud HTTP PUT


PUT /users/Robert HTTP/1.1
Host: myserver
Content-Type: application/xml
<?xml version="1.0"?>
<user>
<name>Bob</name>
</user>

Utilizar PUT para reemplazar el recurso original proporciona una interfaz más limpia, que es coherente
con los principios de REST y con la definición de los métodos HTTP. La solicitud PUT del Listado 5 es
explícita en el sentido de que apunta al recurso que debe ser actualizado identificándolo en la solicitud
de URI, y en el sentido de que transfiere una nueva representación del recurso desde el cliente hacia
el servidor en el cuerpo de una solicitud PUT, en vez de transferir los atributos del recurso como un
conjunto suelto de nombres y valores de parámetros sobre el URI de la solicitud. El Listado 5 también
renombra el recurso de Robert a Bob, y, al hacerlo, cambia su URI a /users/Bob. En un servicio Web de
REST, las solicitudes posteriores para el recurso que utiliza el URI antiguo generarían un error estándar
404 No Encontrado.

Como principio general del diseño, ayuda a seguir las directrices de REST para utilizar métodos HTTP
de forma explícita utilizando nombres en los URIs, en vez de verbos. En un servicio Web de RESTful,
los verbos—POST, GET, PUT y DELETE—ya están definidos por el protocolo. También, idealmente,
el servicio Web no debería definir más verbos o procedimientos remotos, como /adduser o /
updateuser, para mantener la interfaz generalizada y para permitir que los clientes sean explícitos
acerca de las operaciones que invocan. Este principio general del diseño también se aplica al cuerpo
de una solicitud HTTP, que está destinado a ser utilizado para transferir el estado del recurso, no para
llevar el nombre de un método remoto o de un procedimiento remoto a invocar.

Sea sin estado


Los servicios Web de REST tienen que escalar para satisfacer las cada vez mayores demandas de
alto rendimiento. Los clústeres de los servidores que tienen capacidades de balanceo de carga y de
recuperación por error, los proxys y las puertas de enlace, normalmente, se disponen de una manera
que forma la topología de un servicio, lo que permite reenviar las solicitudes de un servidor a otro
según se necesite, para reducir el tiempo de respuesta general de una llamada a un servicio web. Para
utilizar servidores intermediarios para mejorar la escala, los clientes de servicios Web de REST tienen
que enviar solicitudes completas e independientes; es decir, enviar solicitudes que incluyan todos
los datos que se tienen que completar, para que los componentes de los servidores intermediarios
puedan reenviar, redirigir y balancear la carga para no tener que mantener localmente ningún estado
entre las solicitudes.

Una solicitud completa e independiente no requiere que el servidor recupere ningún tipo de contexto
o estado de la aplicación, mientras procesa la solicitud. Las aplicaciones (o clientes) de los servicios
web de REST incluyen, dentro de las cabeceras y cuerpos HTTP de una solicitud, todos los parámetros,
contexto y datos que el componente por el lado del servidor necesita para generar una respuesta.

Servicios Web de RESTful: Los aspectos básicos 第 4 页,共 10


ibm.com/developerWorks/cn/ developerWorks®

El no tener estado en este sentido mejora el rendimiento del servicio Web y simplifica el diseño y la
implementación de los componentes por el lado del servidor, debido a que la ausencia de estado en el
servidor elimina la necesidad de sincronizar los datos de la sesión con una aplicación externa.

La imagen 1 ilustra un servicio sin estado desde el que una aplicación puede solicitar la siguiente
página de un conjunto de resultados de múltiples páginas, asumiendo que el servicio realice el
seguimiento de dónde lo deja la aplicación mientras navega por el conjunto. En este diseño sin estado,
el servicio incrementa y almacena, en algún lugar, una variable previousPage para ser capaz de
responder a las solicitudes de la siguiente.

图 1. Diseño con estado

Los servicios con estado como este se vuelven complicados. En una Plataforma de Java, los servicios
con estado de los entornos Enterprise Edition (Java EE) requieren de muchas consideraciones
previas para almacenar eficientemente y para permitir la sincronización de los datos de la sesión
a lo largo de un clúster de contenedores de Java. En este tipo de entornos, hay un problema
con el que los desarrolladores de servlet/JavaServer Pages (JSP) y Enterprise JavaBeans (EJB)
están familiarizados, a menudo tienen problemas para encontrar la raíz de la causa de una
excepciónjava.io.NotSerializableException durante la replicación de la sesión. Este problema,
tanto si es lanzado por el contenedor del servlet durante una replicación HttpSession como si es
lanzado por el contenedor de EJB durante una replicación de EJB sin estado, es un problema que
puede costar a los desarrolladores días de trabajo intentando identificar un objeto que no implementa
Serializable en un, a veces, complejo gráfico de objetos que constituyen el estado del servidor.
Además, la sincronización de la sesión añade una sobrecarga, que afecta al rendimiento del servidor.

Los componentes sin estado por el lado del servidor, por otro lado, son más fáciles de diseñar, escribir
y distribuir a lo largo de los servidores que tienen la carga equilibrada. Un servicio sin estado no sólo
tiene mejor rendimiento, traspasa la mayor parte de la responsabilidad de mantener el estado a la
aplicación del cliente. En un servicio web de RESTful, el servidor es responsable de generar respuestas
y de proporcionar una interfaz que permita que el cliente mantenga por sí sólo el estado de la
aplicación. Por ejemplo, en la solicitud de un conjunto de resultados de múltiples páginas, el cliente
debería incluir el número actual de la página a recuperar en vez de simplemente pedir la siguiente (vea
la Imagen 2).

Servicios Web de RESTful: Los aspectos básicos 第 5 页,共 10


developerWorks® ibm.com/developerWorks/cn/

图 2. Diseño sin estado

Un servicio web sin estado genera una respuesta que enlaza al número de la siguiente página del
conjunto y deja que el cliente haga lo que tenga que hacer para conservar ese valor. Este aspecto del
diseño de servicios web de RESTful Web se puede desglosar en dos puntos de responsabilidades, como
una separación de alto nivel que clarifica cómo se puede mantener un servicio sin estado:

Servidor

•  Genera respuestas que incluyen enlaces a otros recursos, para permitir que otras aplicaciones
naveguen entre los recursos relacionados. Este tipo de respuesta incorpora enlaces. De forma
similar, si la solicitud se realiza para un objeto secundario o un recurso contenedor, la respuesta
típica de RESTful también podría incluir enlaces a los objetos secundarios del primario o a
recursos subordinados, para que éstos permanezcan conectados.
•  Genera respuestas que indican si se pueden guardar en la memoria caché, para mejorar
el rendimiento al reducir el número de solicitudes de recursos duplicados y al eliminar
completamente algunas solicitudes. El servidor lo hace incluyendo una cabecera de respuesta
HTTP Cache-Control y Last-Modified (una fecha).

Aplicación del cliente

•  Utiliza la cabecera de la respuesta Cache-Control para determinar si guarda el recurso en la


memoria caché (hacer una copia local del mismo). El cliente también lee la cabecera de la
respuesta Last-Modified y envía de vuelta el valor de la fecha en una cabecera If-Modified-Since
para preguntar al servidor si el recurso ha cambiado. Esto se denomina GET Condicional, y las
dos cabeceras van mano a mano en que la respuesta del servidor es un código 304 estándar (No
Modificado), y omite el recurso actual solicitado si no ha cambiado desde ese momento. Un
código de respuesta HTTP 304 significa que el cliente puede utilizar de forma segura una copia
local, guardada en la caché, de la representación del recurso como la más actualizada; de hecho,
elude las posteriores solicitudes GET hasta que el recurso cambie.
•  Envía solicitudes completas que se pueden atender de forma independiente con respecto a las
otras solicitudes. Esto requiere que el cliente utilice completamente las cabeceras HTTP tal como
lo especifica la interfaz del servicio Web, y que envíe representaciones completas de los recursos
en el cuerpo de la solicitud. El cliente envía solicitudes que hacen muy pocas suposiciones acerca
de las anteriores solicitudes, la existencia de una sesión en el servidor, la capacidad del servidor
de añadir contexto a una solicitud, o acerca del estado de una aplicación que se mantiene entre
las solicitudes.

Servicios Web de RESTful: Los aspectos básicos 第 6 页,共 10


ibm.com/developerWorks/cn/ developerWorks®

Esta colaboración entre la aplicación y el servicio del cliente es esencial para que un servicio web de
RESTful sea sin estado. Mejora el rendimiento al ahorrar ancho de banda y al minimizar el estado de la
aplicación por el lado del servidor.

Exponga los URIs como estructuras de directorio.


Desde el punto de vista de las aplicaciones que se encargan de recursos, los URIs determinan
lo intuitivo que va a ser un servicio web de REST y si el servicio se va a utilizar de formas que los
diseñadores puedan anticipar. La tercera característica web de RESTful va sobre los URIs.

Los URIs de los servicios web de REST deberían ser intuitivos hasta el punto en que sean fáciles de
adivinar. Piense en un URI que tenga un tipo de interfaz autodocumentada que requiera poca, o
ninguna, explicación o referencia para que un desarrollador entienda a que apunta y para derivar los
recursos relacionados. Con este fin, la estructura de un URI debería ser bastante clara, predecible y
fácil de entender.

Una forma de lograr este nivel de usabilidad es definir URIs de tipo estructura de directorio. Este tipo
de URI es jerárquico, enraizado como una única ruta y sus ramificaciones son subrutas que exponen las
principales áreas del servicio. Según esta definición, un URI no es meramente una cadena de caracteres
delimitada por barras oblicuas, sino un árbol con ramas subordinadas y superiores que se conectan en
los nodos. Por ejemplo, en un servicio de hebras de discusiones que reúne temas que varían desde Java
hasta el papel, usted puede definir un conjunto estructurado de URIs de esta manera:
http://www.myservice.org/discussion/topics/{topic}

La raíz, /discussion, tiene un nodo /topics bajo ella. Por debajo de eso hay una serie de nombres
de temas, como cotilleos, tecnología, etc., y cada uno de ellos apunta a una hebra de una discusión.
Dentro de esta estructura es fácil extraer hebras de discusiones simplemente escribiendo algo después
de /topics/.

En algunos casos, la ruta hacia un recurso se presta especialmente bien para una estructura tipo
directorio. Por ejemplo, tome los recursos organizados por la fecha, lo que es una buena combinación
para utilizar la sintaxis jerárquica.

Este ejemplo es intuitivo porque se basa en reglas:


http://www.myservice.org/discussion/2008/12/10/{topic}

El primer fragmento de la ruta es un año de cuatro dígitos, el segundo fragmento de la ruta es un día
de dos dígitos y el tercer fragmento es un mes de dos dígitos. Puede parecer un poco absurdo tener
que explicarlo de esta manera, pero es el nivel de simplicidad que estamos buscando. Los humanos y
las máquinas pueden generar fácilmente URIs estructurados como estos, porque se basan en reglas.
Rellenar las partes de la ruta en las ranuras de la sintaxis hace que sean buenos porque hay un patrón
definitivo desde el que componerlos:
http://www.myservice.org/discussion/{year}/{day}/{month}/{topic}

Algunas directrices adicionales interesantes mientras se piensa acerca de la estructura del URI para un
servicio web de RESTful son:

Servicios Web de RESTful: Los aspectos básicos 第 7 页,共 10


developerWorks® ibm.com/developerWorks/cn/

•  Esconder las extensiones del archivo de la tecnología de los scripts por el lado del servidor
(.jsp, .php, .asp), si las tuviera, para poder transportarlo a otro lugar sin cambiar los URIs.
•  Mantenga todo en letra minúscula.
•  Sustituya los espacios con guiones o con subrayados (elegir un tipo).
•  Evite consultar las cadenas de caracteres tanto como pueda.
•  Si el URI solicitado es para una ruta parcial, proporcione siempre como respuesta una página o
recurso predeterminado, en vez de utilizar el código 404 No Encontrado.

Los URIs también deberían ser estáticos, para que cuando el recurso o la implementación del servicio
cambien, el enlace siga siendo el mismo. Esto permite utilizar marcadores. También es importante que
la relación entre los recursos que está codificada en los URIs siga siendo independiente de la forma en
la que se representan las relaciones dónde estás están almacenadas.

Transfiera XML, JSON, o ambos


Una representación de recursos normalmente refleja el estado actual de un recurso y de sus atributos
en el momento en el que una aplicación cliente la solicita. En este sentido, las presentaciones
de recursos son meras instantáneas en el tiempo. Esto podría ser una cosa tan sencilla como la
representación de un registro en una base de datos que está formada por una correlación entre
nombres de columnas y etiquetas XML, dónde los valores de los elementos del XML contienen los
valores de las filas. O, si el sistema tiene un modelo de datos, entonces, según esta definición, una
representación de un recurso es una instantánea de los atributos de una de las cosas del modelo de
datos de su sistema. Estas son las cosas que usted quiere que su servicio web de REST presente.

El último conjunto de restricciones que va en el diseño de un servicio web de RESTful tiene que ver
con el formato de los datos que la aplicación y el servicio intercambian en la carga útil de la solicitud/
respuesta o en el cuerpo HTTP. Aquí es donde realmente compensa mantener las cosas sencillas,
legibles por los humanos y conectadas.

Los objetos de su modelo de datos normalmente están relacionados de alguna manera, y las relaciones
entre los objetos del modelo de datos (recursos) deberían estar reflejadas de forma que estén
representadas para transferirlas a una aplicación cliente. En el servicio de hebras de discusiones, un
ejemplo de representaciones de recursos conectados podría incluir un tema de la discusión raíz, sus
atributos y los enlaces incorporados a las respuestas que se han proporcionado para ese tema.

清单 6. Representación XML de una hebra de una discusión


<?xml version="1.0"?>
<discussion date="{date}" topic="{topic}">
<comment>{comment}</comment>
<replies>
<reply from="joe@mail.com" href="/discussion/topics/{topic}/joe"/>
<reply from="bob@mail.com" href="/discussion/topics/{topic}/bob"/>
</replies>
</discussion>

Y, finalmente, para proporcionar a las aplicaciones del cliente la capacidad de solicitar un tipo de
contenido específico que le venga mejor, construya su servicio de forma que utilice la cabecera HTTP

Servicios Web de RESTful: Los aspectos básicos 第 8 页,共 10


ibm.com/developerWorks/cn/ developerWorks®

Accept incorporada, donde el valor de la cabecera es un tipo MIME. En la Tabla 1 se muestran algunos
tipos MIME habituales que utilizan los servicios de RESTful.

表 1. Tabla 1. Tipos MIME habituales utilizados por los servicios de RESTful


MIME-Type Content-Type

JSON application/json

XML application/xml

XHTML application/xhtml+xml

Esto permite que el servicio sea utilizado por diferentes clientes que están escritos en diferentes
lenguajes y que se ejecutan en diferentes plataformas y dispositivos. La utilización de los tipos MIME
y de la cabecera HTTP Accept es un mecanismo que se conoce como negociación de contenido,
que deja de los clientes elijan cuál es el formato de datos que es adecuado para ellos y minimiza el
acoplamiento de datos entre el servicio y las aplicaciones que lo utilizan.

Conclusión
REST no siempre es la elección adecuada. Fue impuesto como una forma de diseñar servicios Web
con menos dependencia del middleware patentado (por ejemplo, un servidor de aplicaciones) que la
que tienen los del tipo SOAP y los basados en WSDL. Y, de alguna forma, REST es volver a la Web de
la forma en la que era antes de la era de los grandes servidores de aplicaciones, a través de su énfasis
en los primeros estándares, URI y HTTP de Internet. Como hemos vistos en los autodenominados
principios del diseño de la interfaz de RESTful, XML sobre HTTP es una potente interfaz que permite
que aplicaciones internas, como el JavaScript Asincrónico + interfaces de usuario personalizadas
basadas en XML (Ajax), se conecten, manejen y consuman recursos fácilmente. De hecho, el perfecto
ajuste entre Ajax y REST ha incrementado la cantidad de atención que REST está obteniendo estos días.

Exponer los recursos de un sistema a lo largo de una API de RESTful es una forma flexible de
proporcionar diferentes tipos de aplicaciones en las que los datos tengan un formato estándar. Ayuda
a satisfacer los requisitos de la integración que son críticos para construir sistemas en los que los
datos se puedan combinar fácilmente (mashups), y para extender o construir un conjunto de servicios
de RESTful básicos y crear algo mucho mayor. Este artículo tan sólo toca los aspectos básicos, pero,
espero que le haya incitado a continuar explotando el tema.

Servicios Web de RESTful: Los aspectos básicos 第 9 页,共 10


developerWorks® ibm.com/developerWorks/cn/

相关主题
•  Architectural Styles and the Design of Network-based Software Architectures
•  RFC 2616: Hypertext Transfer Protocol-- HTTP/1.1
•  Servicios Web de RESTful

© 版权所有 IBM 公司 2008, 2015
(www.ibm.com/legal/copytrade.shtml)
商标
(www.ibm.com/developerworks/cn/ibm/trademarks/)

Servicios Web de RESTful: Los aspectos básicos 第 10 页,共 10

También podría gustarte