¿Qué me sirve el uso de URL RESTful?

He estado leyendo sobre REST, y estoy tratando de descubrir cuáles son las ventajas de usarlo. Específicamente, ¿cuál es la ventaja de las URL de estilo REST que hacen que valga la pena implementarlas sobre una solicitud GET más típica con una cadena de consulta?¿Qué me sirve el uso de URL RESTful?

¿Por qué es este URL:

http://www.parts-depot.com/parts/getPart?id=00345

considera inferior a esto?

http://www.parts-depot.com/parts/00345

En los ejemplos anteriores (tomado de here) el segundo URL es de hecho más elegante aspecto y conciso. Pero tiene un costo ... la primera URL es bastante fácil de implementar en cualquier idioma web, de fábrica. El segundo requiere código adicional y/o la configuración del servidor para analizar los valores, así como documentación adicional y tiempo dedicado a explicar el sistema a los programadores junior y justificarlo a los compañeros.

Por lo tanto, mi pregunta es, además del placer de tener URL que se ven geniales, ¿qué ventajas obtienen las URL RESTful para que valga la pena el costo de su implementación?

Fuente

2010-04-09 Spike Williams

Simplemente curioso: ¿qué idiomas requieren código adicional y/o configuración para implementar estas últimas URL? – Ken

Estaba pensando específicamente en los servlets de Java. Una simple implementación vainilla de la segunda URL implicaría llamar a request.getURL(), dividir la ruta de URL en tokens y hacer algo con los tokens. Esto no requiere mucho trabajo, pero no es tan limpio como llamar a request.getParameter ("parameterName"). Alternativamente, puede conservar request.getParameter() y hacer que la capa del servidor web reescriba la segunda URL para que se vea como la primera que usa configuraciones de modificación de reescritura ... parece que ese sería el camino a seguir si tuviera que actualizar una un montón de servicios existentes para el nuevo estilo de URL. –

La esperanza es que si usted hace su URL se refiere a un sustantivo, entonces hay una mejor oportunidad que va a poner en práctica los verbos HTTP correctamente. Más allá de eso, no hay absolutamente ninguna ventaja de una URL frente a otra.

La realidad es que el contenido de una URL es completamente irrelevante para un sistema RESTful. Es simplemente un identificador.

No es lo que parece, es lo que haces con eso que es importante.

Fuente

2010-04-10 03:34:12

Uno que siempre me ha gustado como un usuario web inteligente, pero ciertamente no debería utilizarse como un principio rector para saber cuándo utilizar dicho esquema de URL es que esos tipos de URL son "pirateables". En particular, para cosas como los blogs donde puedo simplemente editar una fecha o un número de página dentro de una URL en lugar de tener que encontrar dónde está el botón "siguiente página".

Fuente

2010-04-09 21:10:14

Todas las URL son pirateables. Si confía en personas que no adivinan sus URL como algún tipo de mecanismo de seguridad, lo está haciendo mal y el esquema de URL es el menor de sus problemas. – meagar

Creo que Daniel quiso decir esto más como que en lugar de navegar su IU hinchada y sin sentido, puede encontrar cosas modificando la URL. Esa es ciertamente una de las razones por las que * I * prefiero las URL RESTful. – notJim

@notJim Eso es precisamente lo que quise decir. Si los controles de paginación son malos, no me importa tanto si puedo convertir 'http: // foo.com/article-name/page/1' en' http://foo.com/article-name/ página/2' fácilmente en lugar de tener, digamos 'http: //foo.com/display_article.php? item = 412551' –

Una forma de mirar en reposo:

http://tomayko.com/writings/rest-to-my-wife (que ahora se ha tomado abajo, por desgracia, pero aún se puede ver en web.archive.org)

Así que de todos modos, HTTP-este protocolo Fielding y sus amigos crearon-se trata de aplicando verbos a los nombres. Por ejemplo, cuando vaya a una página web, el navegador hace un HTTP GET en la URL en la que ingresa y regresa a una página web.

...

En cambio, la gran mayoría están ocupados capas escritura de especificaciones complejas para hacer estas cosas en una manera diferente que no es tan útil o elocuente. Los nombres no son universal y los verbos no son polimórficos. Estamos descartando décadas de uso de campo real y probada técnica y comenzando de nuevo con algo que se parece mucho a otros sistemas que han fallado en el pasado. Estamos usando HTTP, pero solo porque nos ayuda a hablar con nuestra red y a las personas de seguridad menos. Estamos comercializando la simplicidad para herramientas llamativas y asistentes .

Fuente

2010-04-09 21:14:52 davek

Una cosa que me salta (buena pregunta por cierto) es lo que describen. El primero describe una operación (getPart), el segundo describe un recurso (parte 00345).

Además, tal vez no podría usar otros verbos HTTP con la primera; necesitaría un nuevo método para putPart, por ejemplo.El segundo puede ser reutilizado con diferentes verbos (como PUT, DELETE, POST) para 'manipular' el recurso. Supongo que también estás diciendo GET dos veces, una vez con el verbo, otra vez en el método, ¿por lo que el segundo es más consistente con la intención del protocolo HTTP?

Fuente

2010-04-09 21:16:03 Brabster

Implícita en esta respuesta, REST es más que simplemente tener buenas URLs. Se trata de utilizar el protocolo HTTP de la manera en que fue diseñado para ser utilizado, es decir, aplicar los verbos/métodos lógicos a sustantivos/recursos/URL. –

"El segundo requiere código adicional y/o de configuración del servidor para analizar cabo valores",

serio? Usted elige un marco pobre, entonces. Mi experiencia es que la versión RESTful es exactamente la misma cantidad de código. Tal vez solo tuve suerte en un marco genial.

"así como documentación adicional y el tiempo dedicado explicar el sistema a los programadores Junior"

Sólo una vez. Después de que lo obtienen, no deberías tener que volver a explicarlo.

"y justificándolo a sus pares".

Solo una vez. Después de que lo obtienen, no deberías tener que volver a explicarlo.

Fuente

2010-04-09 21:32:15

estos son buenos comentarios y estoy de acuerdo con usted. Pero creo que realmente no respondió la pregunta. "Mi pregunta es, aparte del placer de tener URLs que se ven bien, ¿qué ventajas obtienen las URL RESTful para mí que harían que valga la pena el costo de implementación?" –

@Diego Das: La "pregunta" no era sensata. No hay costos de implementación. La premisa fundamental era tres cosas que parecen ser quejas infundadas. –

Todo tiene un costo. Desenterrando la documentación de cómo implementar esta característica en cada uno de los varios marcos que usamos, el tiempo de los costos. Si tengo que enseñar a 10 desarrolladores los métodos que he aprendido, y esa reunión dura 30 minutos, eso le cuesta a mi compañía $ 500. Si tengo que convencer a colegas escépticos para que hagan algo de una manera nueva y elegante, en lugar de intentarlo y hacerlo de verdad, eso me cuesta capital político. Antes de pasar por todo eso, quiero saber si y por qué este cambio vale la pena. –

La mayor ventaja de REST IMO es que permite una forma limpia de utilizar los verbos HTTP (que son los más importantes en los servicios REST). En realidad, usar REST significa que estás usando el protocolo HTTP y sus verbos.

Usando sus URL, e imaginando que desea publicar una "parte", en vez de conseguir que

primer caso debe ser así:

Está utilizando un GET en el que debería haber utilizado un puesto

http://www.parts-depot.com/parts/postPart?param1=lalala&param2=lelele&param3=lilili

Mientras que en un contexto REST, debe ser

http://www.parts-depot.com/parts

una nd en el cuerpo, (por ejemplo) un xml como esto

<part> 
    <param1>lalala<param1> 
    <param2>lelele<param1> 
    <param3>lilili<param1> 
</part>

Fuente

2010-04-09 22:04:51

Creo que esta es la mejor explicación hasta ahora, aunque todavía no estoy convencido de que el estilo RESTful URL esté solucionando algo que no funciona. Todavía es perfectamente posible utilizar GET y POST en la misma URL, independientemente de si utiliza la consulta en la solicitud GET o si almacena esos datos en la URL. ¿Por qué esa solución está en desuso en favor de las URL RESTful? ¿Realmente se reduce a "limpiar" URLs que son agradables tener por su propio bien? ¿O hay algo que pueda hacer con las URL REST que simplemente no funcionarían bajo un paradigma de solicitud HTTP simple? –

Como dije en la respuesta (tal vez no fui lo suficientemente claro), REST tiene la intención de usar verbos HTTP, ya que fueron diseñados para ... Puede hacer cualquier cosa con GET/POST. Sin embargo, ¿cómo se debe actualizar un recurso idempotente sin el PUT VERB? Puedes hacerlo usando un POST e incluso un GET, pero si hay un VERBO en el Protocolo HTTP para hacer esto, ¿por qué no lo usas? Debería ser más limpio, más fácil de entender y, como usará el protocolo de todos modos, úselo como lo esperaría el protocolo en sí ... :) –

No existe una URL REST. – SerialSeb

La semántica de URI está definida por RFC 2396. Los extractos particularmente pertinentes a esta pregunta son 3.3. "Ruta del componente":

El componente de ruta de acceso contiene datos, específicos a la autoridad (o el esquema si no hay ningún componente autoridad), que identifican el recurso dentro del alcance de dicho sistema y la autoridad.

Y 3.4 "componente de consulta":

El componente de consulta es una cadena de información a ser interpretado por el recurso.

Tenga en cuenta que el componente de consulta no es parte del identificador de recursos, es meramente información que el recurso debe interpretar.

Como tal, el recurso identificado por su primer ejemplo es realmente /parts/getPart. Si su intención es que la URL identifique un recurso de parte específico, el primer ejemplo no lo hace, mientras que el segundo (/parts/00345) lo hace.

Por lo tanto, la 'ventaja' del segundo estilo de URL es que es semánticamente correcta, mientras que la primera no lo es.

Fuente

2010-04-11 17:26:30

Esa es una cita fascinante. Tendré que profundizar en eso más ya que he visto a Roy hacer declaraciones en algunas ocasiones que parecen estar en contradicción directa con eso. –

Echa un vistazo a RFC3986 que reemplaza a RFC2396 http://labs.apache.org/webarch/uri/rfc/rfc3986.html#query. En la sección de consulta 3.4 hay la siguiente cita * El componente de consulta contiene datos no jerárquicos que, junto con los datos en el componente de ruta, sirven para identificar un recurso dentro del alcance del esquema del URI * –

Hmmm interesante ... No tuve No se dio cuenta de que la semántica había sido modificada por el RFC actualizado. Leí el original hace años; Solo asumí que la actualización no alteraría significativamente la semántica. Eso me enseñará a estar detrás de los tiempos. De acuerdo, parece que en 2004 esta respuesta habría sido correcta, pero ahora está mal: -S –

No utilice las partes de búsqueda/búsqueda en URL que no son consultas o búsquedas; si lo hace, de acuerdo con la especificación de la URL, probablemente esté implicando algo sobre ese recurso que realmente no desea.

Utilice las partes de la consulta para los recursos que son un subconjunto de un recurso más grande - la paginación es un buen ejemplo de dónde esto podría aplicarse.

Fuente

2010-04-13 11:36:59 Mike

¿Qué me sirve el uso de URL RESTful?

Respuesta

Cuestiones relacionadas