¿La API de Twitter * realmente * es RESTful?

Question

Junto con la mitad de la comunidad de desarrolladores web, he estado luchando por asimilar de verdad el estilo REST. Más específicamente, he estado tratando de formarme una opinión sobre cuán práctica es realmente una arquitectura RESTful pura entre un navegador web y un servidor de aplicaciones.

Como parte de mi esfuerzo de aprendizaje, he echado un vistazo a algunos ejemplos en línea de REST, específicamente Twitter en este caso. En su API documentation, discuten sus diversos "métodos REST API".

Estoy luchando con la racionalización de cómo exactamente la mayoría de estos son realmente RESTful, más allá de tener una estructura de URL RESTful. Considere, por ejemplo, una simple solicitud GET a http://twitter.com/favorites.

En una implementación pura de REST, esperaría que las solicitudes idénticas a esa URL, independientemente del cliente que inicia, devuelvan respuestas idénticas. Sin embargo, en este caso particular, obviamente todos veríamos diferentes respuestas dependiendo de nuestros usuarios actualmente autenticados, lo que implica que nuestras solicitudes se están conectando a algún tipo de estado de cliente en el servidor antes de que se pueda generar una respuesta.

Afortunadamente eso proporciona suficiente contexto para mi pregunta, entonces - ¿realmente se puede llamar "REST"? Me da la impresión de que el 90% de las llamadas implementaciones RESTful entre navegadores web y servidores de aplicaciones demuestran esta misma inconsistencia, donde se ignoran las restricciones sobre el estado del cliente almacenado en el servidor.

Answer 1

Twitter rompe prácticamente todas las restricciones de REST. Su ejemplo de http://twitter.com/favorites que arroja resultados diferentes en función del usuario autenticado es un ejemplo de Twitter que viola la restricción de "Identificación de recursos". Cada recurso interesante debe tener un identificador único. Mis favoritos de Twitter y sus favoritos de Twitter son dos recursos diferentes y, por lo tanto, deberían tener dos URI diferentes.

Esto en realidad no está relacionado con la idempotencia en absoluto. Idempotencia se trata de poder hacer la misma solicitud varias veces y tiene el mismo efecto. Incluso Twitter respeta la idempotencia. Si OBTENGO mis favoritos varias veces, sigo recibiendo mis favoritos. Cuántas veces lo hago GET no afecta el resultado.

Hay muchas otras maneras en que Twitter rompe las restricciones REST. Muchos de estos problemas han sido tratados aquí en SO antes.

actualización Después de leer los docs API de Twitter un poco más no es en realidad un formato URI alternativo que identifique correctamente el recurso de favoritos. Here que muestran cómo crear una URL como:

http://api.twitter.com/1/favorites/bob.json 

Es todavía un largo camino de ser REST, pero al menos es un paso en la dirección correcta.

Answer 2

En este contexto, idempotence es una palabra difícil. Incluso si estuviera recuperando un tweet individual, obtendría un resultado diferente si ese tweet fuera editable y alguien lo editara. Al recuperar una lista, ciertamente esperaría que un tweet recuperara la lista más reciente.

Podría ser más útil pensar en idempotencia como la capacidad de hacer algo sin causar efectos secundarios. Entonces un GET es idempotente en este sentido, pero un POST no lo es.

From Wikipedia:

En informática, el idempotente término se utiliza para describir los métodos o llamadas a subrutinas que pueden ser de forma segura llamados varias veces, como invocando el procedimiento una sola vez o varias veces tiene el mismo resultado; es decir, después de cualquier cantidad de llamadas a métodos todas las variables tienen el mismo valor que después de la primera llamada. Cualquier método o subrutina que no tenga efectos secundarios también es idempotente.

También from Wikipedia:

Métodos PUT y DELETE se definen a idempotente, lo que significa que múltiples solicitudes idénticas deben tener la mismo efecto que una única solicitud.

En contraste, el método POST no es necesariamente idempotente, puesto el envío de una solicitud POST idéntica varias veces puede afectar aún más estado o causar otros efectos secundarios (tales como las transacciones financieras [por ejemplo,un cliente recibe un error por dos veces por el mismo producto]).

Consulte también:

Como he explicado a mi esposa RESTO
http://tomayko.com/writings/rest-to-my-wife

Answer 3

Técnicamente, no, no es reparador. No es stateless (por ejemplo idempotent como lo mencionó) por una cosa.

Answer 4

Como explica el REST FAQ, el término "REST" se utiliza para abarcar una amplia gama de cosas, incluidas las aplicaciones con estado que se estructuran en un estilo RESTful. Debido a que el estado pasa principalmente por el usuario en una cookie en lugar de almacenarse en el servidor, se considera RESTful. Roy Fielding (que inventó REST) ​​commented que, mientras el estado entero pase por el usuario, en lugar de una referencia al estado en el servidor, es RESTful, ya que la misma solicitud GET arrojará el mismo resultado. La API REST de Twitter está cerca de hacer esto, pero no está al 100% allí. No es estrictamente el significado original de "DESCANSO", pero la interfaz y la filosofía general son lo suficientemente similares como para que generalmente se maneje bajo el mismo paraguas.

Answer 5

En cuanto al documentation, el uso de la palabra "método" es probablemente una buena indicación de si la API es realmente RESTful o no. Hay un par de recursos que en realidad podrían calificar como tales, como friends/<user-id> o favourites/<user-id>, pero la mayoría de los recursos son en realidad procedimientos simples, como account/update_profile_image por ejemplo.

La forma en que lo veo, en REST URI debe realmente sólo una cosa specifiy , y no lo que se va a hacer con él. Si hay un verbo en el URI (como actualización), lo más probable es que lo estés haciendo mal.

Answer 6

Leyendo la API de Twitter He llegado al entendimiento de que la API RESTful estará obsoleta en un par de semanas. En su lugar, debe usar el método de autenticación OAuth.