REST y servicios web: tiene problemas para entenderlos

Question

Bueno, el título más o menos lo dice todo. En cierto modo, entiendo qué es REST: el uso de procedimientos HTTP existentes (POST, GET, etc.) para facilitar la creación/uso de servicios web. Estoy más confundido sobre qué define qué servicio web es y cómo REST se usa realmente para hacer/exponer un servicio.

Por ejemplo, Twitter, por lo que he leído, es RESTful. ¿Qué significa eso realmente ? ¿Cómo se invocan los procedimientos HTTP? Cuando escribo un tweet, ¿cómo está involucrado el REST, y cómo es diferente de simplemente usar un lenguaje del lado del servidor y almacenar esos datos de texto en una base de datos o archivo?

Answer 1

Este concepto también es un poco vago para mí, pero después de ver tu pregunta, decidí aclarar un poco más para mí.

consulte el enlace this en msdn y this.

Básicamente parece que se trata de usar métodos http (Get/Post/Delete) para identificar la exposición de recursos que permite la aplicación. Por ejemplo: Digamos que tienes la URL:

http://Mysite.com/Videos/21 

donde 21 es un id de un video. Podemos definir con mayor detalle qué métodos están permitidos en esta url: GET para recuperar el recurso, POST para actualizar/Crear, Eliminar para eliminar.

En general, parece que de forma organizada y limpia para exponer sus recursos de aplicación y las operaciones que se apoyan en ellos con el uso de métodos HTTP

Answer 2

Una arquitectura REST proporciona una URL única que define cada recurso individual y deduce a través de verbos de acción HTTP la acción apropiada para la misma URL.

La mejor manera de explicarlo es pensar en cada modelo de datos en su aplicación como un recurso único, y REST ayuda a enrutar las solicitudes sin utilizar una cadena de consulta al final de la url, por ejemplo, en lugar de /posts/&q=1, simplemente usaría posts/1.

Es más fácil de entender a través del ejemplo. Esta sería la arquitectura REST implementada por Rails, pero le da una buena idea del contexto.

• GET /tweets/1 ⇒ significa que desea obtener el tweet con el id de 1
• GET /tweets/1/edit ⇒ significa que quiere ir a la acción de edición que se asocia con el tweet con un id de 1
• PUT /tweets/1 ⇒ PUT dice a actualizar este tweet no recupera su
• POST /tweets ⇒ Post dice que tengo una nueva, añadirlo a la db, no puedo dar un id porque yo no tiene uno todavía hasta que guardarlo en la db
• DELETE /tweets/1 ⇒ eliminarlo de la base de datos

recursos a menudo se anidan, aunque por lo que en Twitter que podría ser como

• GET /users/1/jedschneider/1 usuarios ⇒ tienen muchos tuits; conseguir que el usuario con id de jedschneider y su Tweet ID 1

La arquitectura para implementar resto será única para la aplicación, con algunas aplicaciones de soporte de forma predeterminada (como rieles).

Answer 3

Es posible que desee comenzar con this excellent introductionary writeup. Lo cubre todo, de principio a fin.

Answer 4

Está luchando porque hay dos entendimientos relativamente diferentes del término "REST". Tengo attempted to answer this earlier, pero basta con decir: la API de Twitter no es RESTful en sentido estricto, y tampoco lo es Facebook.

respuesta de sTodorov muestra la commonmisunderstanding que se trata de utilizando los cuatro verbos HTTP, y la asignación de diferentes URIs a los recursos (por lo general con la documentación de lo que todas las URIs son). Por lo tanto, cuando Twitter invoca REST simplemente lo hacen, junto con la mayoría de las demás RESTful API.

Pero este llamado REST es no diferente de RPC, excepto que RPC (con IDL o WSDL) podría introducir instalaciones de generación de código, a costa de un mayor acoplamiento.

REST es en realidad no RPC. Es una arquitectura para sistemas distribuidos basados ​​en hipermedia, que podría no ser la mejor para todos los que hacen una API. En el ligado MSDN artículo, las patadas hipermedia en cuando hablan de <Bookmarks>http://contoso.com/bookmarkservice/skonnard</Bookmarks>, la sección termina con esta frase:

Estas representaciones hacen es posible navegar entre los diferentes tipos de recursos

que es el principio básico que viola la mayoría de las API RESTful. El artículo no indica cómo document a RESTful API y, si lo hiciera, sería mucho más claro que los clientes tendrían que navegar por los enlaces para poder hacer las cosas (RESTful) y no se les proporcionarían muchas plantillas de URI (RPCish) .