Servicios web RESTful: tratando de lograr HATEOAS con XML personalizado

Question

Estoy trabajando en un sistema empresarial que utilizará un servicio web RESTful entre clientes móviles y un servidor central. Lo más RESTANTE posible, digamos.

Mi pregunta se refiere a HATEOAS (hipermedia como el motor del estado de la aplicación) y al uso de xml personalizado en los cuerpos de respuesta HTTP.

Este sistema nunca jamás pueden utilizar clientes públicos, pero me gusta la idea HATEOAS de ser capaz de modificar el patrón de asignación de recursos de servidor más tarde sin tener que volver a configurar cada uno de los clientes de manera independiente. Si decidimos que debido a problemas de escalabilidad necesitamos extender la función del servidor en múltiples cuadros físicos, no hay problema, esto se reflejará en los URI que se generan cuando un cliente (o el servidor bajo instrucciones de un cliente) crea un nuevo recurso .

Nuestro dominio comercial es muy específico e inusual. Como tal, me gustaría utilizar XML personalizado para cuerpos de entidades de respuesta HTTP en todo el servicio web, y el cliente analizará los URI de recursos del xml para mantenerse informado de las ubicaciones de recursos que puede usar al modificar su propio estado de aplicación. Sé que esto 'rompe' la parte H de HATEAOS.

p. Ej. cuando un cliente envía una transacción al servidor para su procesamiento, el servidor puede incluir el siguiente fragmento xml en el cuerpo de respuesta HTTP 201 (como parte de un documento xml más grande). El servidor también informaría al cliente del URI para el recurso de transacción recién creado, pero probablemente solo se incluiría en el encabezado HTTP de ubicación.

<resulturi>http://resultserver/results/1234.xml</resulturi> 

¿Es esta tan malo? Hay muy pocas posibilidades de que los clientes que usen este servicio estén basados ​​en el navegador. ¿Cuáles son las otras ventajas de hipermedia sobre la entrega de uris como texto sin formato dentro de xml?

Supongo que podría ir a XHTML, pero el analizador en nuestra plataforma móvil es mucho más eficiente con POX.

Answer 1

Lo que está haciendo al devolver una url en resulturi ya es efectivamente hipermedia. El único problema es que necesita un tipo de medio que le indique al cliente cómo se formatea la respuesta para que pueda analizar las URL de una manera predecible y documentada.

Opción 1: Cree su propio tipo de medio como vnd.yourcompany.Resource + xml. Al hacer esto, usted indica que el tipo de medio puede ser analizado por un analizador xml, pero sigue algunas reglas especiales definidas por su compañía. En este punto, puede usar cualquier estándar que desee para definir enlaces hipermedia (consulte la pregunta this). Una buena ventaja de esto es que si en 6 meses decide que necesita realizar un cambio radical en el formato de su XML, puede crear una vnd.yourcompany.ResourceV2 + xml y siempre que sea lo suficientemente inteligente como para utilizar la aceptación. encabezado en sus clientes anteriores, puede introducir sin problemas el nuevo formato al lado del anterior haciendo que las nuevas aplicaciones cliente acepten el nuevo formato.

Opción 2: Solo estoy hablando en serio sobre esta opción, pero he considerado la posibilidad de buscar un nuevo tipo de medio llamado application/hyperxml + xml. El documento seguiría las mismas reglas que application/xml pero también haría uso de XLink para hipermedia. Esto permitiría a las personas que usan javascript analizar el documento XML para que también aprovechen los hipermedios de una manera estandarizada.

Opción 3: Usa XHtml. No entiendo por qué tu analizador tiene problemas con Xhtml, pero tomaré tu palabra para eso.

Answer 2

Hay dos datos importantes que su servidor RESTful necesitará para procesar las solicitudes, independientemente del lenguaje de marcado subyacente: un tipo de medio y un URI. Suponiendo que un tipo de medio para un URI dado introduciría el acoplamiento cliente-servidor. Sería, por ejemplo, evitar que el mismo URI nunca sirva dos tipos diferentes de tipos de medios.

XML no es la única opción cuando se diseñan formatos hipermedia. Consulte Sun Cloud API, que define una API REST hypertext-driven basada en JSON (aunque parece que no utiliza el tipo de medio con sus hipervínculos). No es difícil pasar de este enfoque a uno que combine tipos de medios con hipervínculos.

Por ejemplo, puede definir una estructura de datos JSON llamada Enlace que se parece a esto;

{ 
    "name":"human-readable label for link", 
    "uri":"http://example.com/resources/123", 
    "media_type":"application/vnd.com.example.Resource+json" 
} 

Answer 3

Hipermedia no requiere HTML o incluso URI totalmente cualificados para el caso. Si su tipo de medio define una regla para convertir algunos elementos de la respuesta en recursos des-referenciables, entonces tiene hipermedia.

<result>1234</result> 

el ejemplo anterior, combinado con una regla de tipo de medio sobre la forma de eliminar la referencia al contenido del elemento resultado es hipermedia de la misma manera que:

<result>/foo/1234</result> 

es con una regla para anteponer la base http URI. Así es el siguiente ejemplo donde el hecho de que la cadena http sea desreferenciable puede quedar implícito.

<result>http://myserver.com/foo/1234</result> 

Sin embargo, aunque todos ellos son hipermedia y conoce a esa restricción, sostendría contra la creación de sus propias nuevas reglas de producción hipermedia y las etiquetas si es posible y sólo volver a utilizar los ya existentes. El primer ejemplo hace que sea menos obvio para el usuario que este elemento representa un recurso hipervinculado que el último ejemplo.

Answer 4

Sugeriría que en lugar de codificar manualmente estos hipervínculos, use una herramienta que cree esos hipervínculos para usted. La programación orientada a la interacción es un buen método para crear estas interacciones (hipervínculos). Por favor, siga este enlace esta tecnología funcionó para nosotros http://www.masterkube.com/hateoas_technology.html

Answer 5

Como mínimo (incluso si usted no hace nada), usted debe poner su URL en un atributo en lugar del contenido del elemento XLink:

<resulturi xlink:href="http://resultserver/results/1234.xml"/> 

XML los procesadores pueden analizar y seguir estos como URI de forma nativa. Como regla general, el texto que no es traducible o que nunca podría tener subelementos debería estar en un atributo para aplicar tales restricciones.

Pero más allá de esto, haga lo que otros han sugerido y defina su tipo de medio para que los clientes entiendan el significado.