¿Cómo pasar consultas complejas en REST?

Question

Si entiendo correctamente, en el estilo de reposo, cada consulta (es decir, cada acción en cada recurso que no modifica el estado del recurso) debe codificarse en la cadena de consulta, utilizando un método get, sin cuerpo en absoluto.

¿Estoy en lo cierto?

Bueno, tengo varias aplicaciones que se comunican con el DB a través de un mensaje XML que es manejado por un componente de Visual Basic 6.

el mensaje para una consulta es algo como esto

<xml> 
    <service>account</service> 
    <resource>invoice</resource> 
    <action>query</action> 
    <parameters> 
    <page>1</page> 
    <page_len>10</page_len> 
    <order>date</order> 
    <fields>*</fields> 
    <conditions> 
     <date>2009-01-01..2009-01-31</date> 
     <customer_id>24</customer_id> 
    </conditions> 
    </parameters> 
</xml> 

En este momento estamos en el proceso de rediseño de nuestros mensajes XML, y nos gustaría hacer eso de una manera tal que puedan ser fácilmente mapeado a una interfaz RESTful.

En el ejemplo anterior, necesitamos las etiquetas de "condiciones" para evitar colisiones entre los parámetros y las condiciones (es decir, qué sucede si tengo un campo llamado "orden", "página" o algo así. ..

Pensamos sobre el envío de los parámetros con un prefijo, algo así como

http://account/invoice/?_page=1&_page_len=10&_order=date&_fields=*&date=2009-01-01..2009-01-31&customer_id=24 

y el XML sería algo así como

[...] 
    <_order>date</_order> 
    <_fields>*</_fields> 
    <date>2009-01-01..2009-01-31</date> 
    <customer_id>24</customer_id> 
[...] 

Nosotros están tratando de definir un formato XML realmente simple para operaciones crud, y que el XML resultante podría ser fácilmente mapeado a reposo o JSON.

¿Cómo asignaría ese tipo de consulta en una aplicación de descanso? ¿Hay algún estándar definido? o alguna página con muestras crud rest/XML/JSON? ¿Qué hay de devolver el error, o datasets anidados?

Muchas gracias.

Answer 1

en mi humilde opinión con el fin de hacer que su sistema sea verdaderamente RESTful, debe replantear todos los mensajes/consultas que va a enviar.

Esta parte:

<conditions> 
    <date>2009-01-01..2009-01-31</date> 
    <customer_id>24</customer_id> 
</conditions> 

es la parte difícil. ¿Qué tipo de otras condiciones tienes? ¿Hay muchos? Este ejemplo particular me hace pensar que puede tratar las facturas como un subrecurso de un cliente. Cuando descanso, siempre trato de identificar recursos en la ruta y si una consulta aún necesita algún parámetro, los muevo a la cadena de consulta. Así que escribiría algo como esto:

GET /customers/24/invoices?start_date=2009-01-01&end_date=2009-01-31 

Piense en las relaciones entre sus recursos. Supongamos que tenemos un tipo de recurso relacionado con el tipo de recurso de Foo Bar por una relación de -to-many. En este caso, puede preguntar acerca de esta relación como esta: GET /foo/123/bar y agregar parámetros de cadena de consulta para filtrarla. El problema comienza cuando desea filtrarlo de una manera que implique relaciones con otros recursos. En mi humilde opinión, esto significa que su diseño de recursos no es realmente RESTful.

Answer 2

Tendría que codificar en la URL el xml para poder pasarlo, pero, si convirtió el xml a json, podría pasar esa cadena y luego json-> xml o json-> object para procesarla. Esto le permitiría pasar objetos más complejos.

No es perfecto, pero funciona. :)