RESTO - URI múltiple para el mismo recurso (???)

Estoy escribiendo un artículo sobre la implementación de un servicio REST para los trabajos de investigación de una universidad y tengo un pequeño problema para entender la relación entre los URI y los recursos.RESTO - URI múltiple para el mismo recurso (???)

Dice que un recurso puede tener un URI o muchos. Pues aqui esta mi problema. Quiero hacer que este servicio sea muy fácil de usar y para evitar la información: se debe acceder a un recurso desde diferentes puntos de entrada, pero esto va en contra del concepto de que cada "URI designa exactamente un recurso".

Así que mi pregunta es si el siguiente es o no es de conformidad con el descanso lo siguiente:

Quiero exponer información sobre una publicación de investigación (digamos que un peer reviewed).

Esto se puede acceder mediante este URI: UNIVERSITY/publications/{my_publication}.

Pero ya que este documento ha sido escrito por un investigador que trabaja en el digamos Facultad de Ciencias Sociales, que también hará que el sentido de que la publicación tiene esta URI: UNIVERSIDAD/facultades/social_science/publicaciones/{my_publication}.

Además, como el servicio también expone a todos los investigadores que trabajan en la universidad (por ejemplo, UNIVERSITY/researchers/{my_researcher}) también tendrá sentido que la publicación se llame UNIVERSITY/researchers/{my_researcher}/publications/{my_publication}.

Esto podría continuar con múltiples usos, pero se entiende.

¿Esto está de acuerdo con REST o no?

¿Puedo guardar esto y resolver el dilema enviando un código de respuesta 303 ("Ver también") junto con el URI canónico (que será UNIVERSITY/publications/{my_publication}).

¡Gracias de antemano!

Fuente

2009-12-18 Anonymous

Dice que un recurso puede tener un URI o muchos. Pues aqui esta mi problema. Quiero hacer que este servicio sea muy fácil de usar y para evitar la información: se debe acceder a un recurso desde diferentes puntos de entrada, pero esto va en contra del concepto de que cada "URI designa exactamente un recurso".

No creo que haya ninguna contradicción aquí. Un URI puede apuntar como máximo a un recurso, pero muchos URI pueden apuntar al mismo recurso. Una relación muchos a uno entre los URI y los recursos, si se quiere.

Dicho esto, no me asustaría demasiado si su aplicación es RESTful o no. Es solo un principio de diseño. Aquí hay un buen artículo de un tipo que argumenta que REST no está diseñado para humanos con navegadores web de todos modos: http://starkravingcoder.blogspot.com/2009/01/where-are-rest-frameworks.html

Fuente

2009-12-18 16:44:09 danben

Si bien cada recurso de publicación debe tener un único nombre de recurso (URI), usted es libre de crear recursos que son consultas y listas de devolución de otros nombres de recursos.

Puede tener UNIVERSITY/publication/{publication} como el patrón de nombre de recurso para recursos de publicación, y UNIVERSITY/faculties/{faculty}/publications como el patrón para nombrar recursos que son listas de publicaciones para facultades particulares.Del mismo modo, UNIVERSITY/researchers/{researcher}/publications podría ser el patrón de nombre de recurso para las listas de publicaciones creadas por una persona en particular.

Fuente

2009-12-18 16:46:37

Hola Jim, eso es exactamente lo que hice. Incluso fui más allá, pero también mencioné recursos para cada publicación de institutos (/ facultad/instituto/publicaciones), etc. Ese no es mi dilema, pero el hecho de que no importa qué URI tengo frente a {my_publication}, el URI apunta a un mismo recurso: la publicación en sí misma, que es única. –

@jan, No estoy seguro si esto responde a su comentario, pero cada consulta puede ser un recurso REST tal como lo es cada publicación. Una consulta debería contener solo una lista de publicación * nombres *. Por lo tanto, un cliente de su servicio web puede obtener primero la lista de todas las publicaciones del Instituto de Ciencias de la Información de la USC, y luego obtener cada publicación en esa lista. –

+1 a Jim Ferrans.

Además, tener exactamente un URI por recurso facilitará la creación de enlaces dentro de su sitio. He leído que los motores de búsqueda prefieren que el contenido no se repita en diferentes URI también.

Fuente

2009-12-18 16:58:15

Eso es cierto, y otra ventaja es que si solo tiene un único nombre por recurso, entonces es mucho más accesible que si tuviera un montón de sinónimos. –

Dice que un recurso puede tener un URI o muchos. Pues aqui esta mi problema. Quiero hacer de este servicio muy fácil de usar y de moverse por la información: un recurso debe acceder desde diferentes puntos de entrada, pero esto va a ir en contra de la idea, de que cada "URI designa exactamente un recurso"

n no es así "Cada dedo pertenece exactamente a una mano" no implica que "cada mano tiene exactamente un dedo". "Cada URI designa exactamente un recurso" no implica "que cada recurso esté designado por exactamente un URI".

Dicho esto, un redireccionamiento a un URI canónico mejoraría algunos casos de uso (como dos usuarios que marcan el mismo papel en delicious, que han llegado desde diferentes consultas).

También parece estar pensando en construir URL a través de patrones jerárquicos, en lugar de cualquier cosa sobre REST. Las aplicaciones REST utilizan "hipertexto como motor del estado de la aplicación". La forma del URI es irrelevante, lo que importa es que es navegable desde la representación devuelta en el punto de entrada de la aplicación. Fielding lo deja claro en su blog REST APIs must be hypertext-driven como un anti-patrón causando acoplamiento entre el cliente y el servidor:

una API REST no debe definir los nombres de recursos fijos o jerarquías (un acoplamiento evidente de cliente y servidor).

Fuente

2009-12-18 17:46:16

Chico me gustaría que expandas un poco ese último párrafo. – ScottCher

@ScottCher En una aplicación REST, el estado de la aplicación está representado por el agente de usuario que busca recursos a través de las URL. REST está pensando en una aplicación como una máquina de estado donde cada estado es el resultado de resolver una URL para recuperar un recurso; los enlaces en el recurso son las transiciones a los siguientes estados posibles. Tener los enlaces con un patrón legible por humanos en particular no es relevante para REST, solo que los enlaces al siguiente estado de la aplicación se encuentran dentro del recurso recuperado para el estado actual. Tener el mismo estado representado por la misma URL facilita ... –

... marcadores, pero tener un patrón que los usuarios puedan adivinar es algo anti-REST: significa que un usuario puede adivinar una URL, escribirla y saltar a una aplicación declara que no era parte de su flujo de trabajo. Para muchos casos, esto no es un problema, donde el estado no depende de que se haya llegado a él desde una ruta determinada, por lo que muchas aplicaciones REST lo permiten. Tener un buen patrón de lectura humana tiene ventajas, pero no es un requisito de REST. –

Este es un tema que se debate con frecuencia y creo que la confusión se basa en tratar de comprender a qué se refiere realmente un URI HTTP. Basado en mis lecturas, esto se convierte en un tema realmente peludo y las personas mucho más inteligentes que yo debatieron durante muchos años sobre el tema.

Here es la página de resumen de toda la discusión sobre el problema http-range-14.

Mi interpretación ingenua de la conclusión final de este problema es que solo debe haber un único URI que devuelva un "recurso de información" físico con un 200. Sin embargo, puede haber muchos URI que se refieren al recurso como un puro concepto. Devolver 303 le permite vincular el concepto a "recurso de información".

Así que la respuesta es sí y no, puede haber varios URI para el mismo recurso y todos son válidos para representar el concepto, pero solo uno debe devolver la representación física.

Esto es consistente con un comentario reciente de Roy Fielding al hablar sobre el uso de ".xml" y ".json" en los URI. Afirmó claramente que http://www.example.org/myresource.xml y http://www.example.org/myresource.json hacen referencia a dos RECURSOS diferentes porque ambos devuelven un 200. Sin embargo, cuando utiliza la negociación de contenido en http://www.example.org/myresource, puede recuperar dos representaciones diferentes del mismo recurso.

Fuente

2009-12-18 18:31:23

Necesita ver la diferencia entre un recurso y la entidad que representa. Roy Fielding escribe en su dissertation, section 5.2.1.1:

Un recurso es un mapeo conceptual de un conjunto de entidades, no la entidad que corresponde a la asignación en cualquier punto particular en el tiempo .

Dado que todos sus recursos tienen una semántica ligeramente diferente, se puede considerar como RESTful mi opinión. Según la estructura de su tipo de medio, puede usar el canonical link relation para indicar el "uri preferido".

Fuente

2015-06-04 12:05:25

RESTO - URI múltiple para el mismo recurso (???)

Respuesta

Cuestiones relacionadas