Cómo pasar de consultas complejas en el RESTO?

Question

Si he entendido bien, en el resto estilo, cada consulta (que es, en cada acción, en cada recurso que no modifica el estado del recurso) debe ser codificado en la cadena de consulta, utilizando el método get, sin cuerpo.

Estoy en lo cierto?

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

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>

Ahora estamos en el proceso de rediseño de nuestros mensajes XML, y nos gustaría hacerlo de tal manera que ellos pueden ser fácilmente asignados a una interfaz RESTful.

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

Nosotros a pesar de que 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 como

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

Estamos tratando de definir algunos realmente simple formato XML para realizar operaciones crud, y que el XML resultante podría asignarse fácilmente a descansar o JSON.

¿Cómo asignar ese tipo de consulta en una aplicación rest?Hay algunas estándar definido?o alguna página con impurezas de descanso / XML /JSON muestras?cómo sobre la devolución de error, o dentro de los conjuntos de datos?

Muchas gracias.

Answer 1

En mi humilde opinión, con el fin de hacer que su sistema verdaderamente Reparador debe repensar todos los mensajes y consultas que se 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é otra clase de condiciones tiene?¿Hay muchos?Este ejemplo en particular me hace pensar que se puede tratar a las facturas como un subresource de un cliente.Cuando hago resto yo siempre trato de identificar los recursos en el camino y si una consulta stil necesidades de los parámetros, me muevo a la cadena de consulta.Así que me gustaría escribir algo como esto:

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

Pensar acerca de las relaciones entre sus recursos.Supongamos que tenemos el tipo de recurso Foo de recursos relacionados con el tipo de la Barra por una -a-muchos de relación.En este caso, usted puede preguntar acerca de esta relación como esta: GET /foo/123/bar y añadir parámetros de cadena de consulta para filtrar.El problema comienza cuando se desea filtrar de una manera que implica relaciones con otros recursos.En mi humilde opinión, esto significa que su recurso de diseño no es realmente Relajante.

Answer 2

Usted tendría que cifrar la URL de la xml para poder pasar, pero, si usted convirtió el XML a JSON, entonces podría pasar esa cadena y luego json-> xml o json-> objeto de procesarla. Esto le permitiría pasar objetos más complejos alrededor.

No es perfecto, pero funciona. :)