2012-01-24 8 views
5

Estoy intentando crear un mecanismo de consulta más avanzado para REST. Supongamos que tengo lo siguiente:Consultas avanzadas en REST

GET /data/users 

y devuelve una lista de usuarios. Luego, para filtrar los usuarios devueltos, por ejemplo, diría:

GET /data/users?age=30 

para obtener una lista de usuarios de 30 años. Ahora digamos que desea que los usuarios de entre 30 - 40. Me gustaría tener esencialmente un conjunto de operadores reutilizables tales como:

GET /data/users?greaterThan(age)=30&lessThan(age)=40 

El greaterThan y lessThan sería reutilizable en otro numérico, fecha, etc campos. Esto también me permitiría agregar otros operadores (contiene, comienza con, termina con, etc.). Soy un novato de REST, así que no estoy seguro de si esto infringe alguno de los principios básicos que sigue REST. ¿Alguna idea?

+0

La plataforma MS Dynamics 2011 hace algo similar con la interfaz oData. http://msdn.microsoft.com/en-us/library/gg309461.aspx Tal vez esto le dará cierta información. – user1231231412

+0

Wow gracias por el enlace, eso es realmente útil para ver cómo alguien como Microsoft lo implementó. – NorthFork

+0

Gracias a todos por los comentarios, ha sido útil. – NorthFork

Respuesta

1

Alternativamente, puede que simplemente sea mejor con los parámetros opcionales "minAge" y "maxAge".

Alternativa 2: codificar el valor (s) de parámetros para indicar la prueba a realizar: desigualdades, la coincidencia de patrones, etc.

Esto se complica, no importa lo que haces para expresiones booleanas complejas. En algún momento, casi desea crear un formato de documento para la descripción de la consulta en sí, pero ya es difícil pensar que se trata de un "GET".

1

Me gustaría ver en establecer el valor del parámetro de consulta para incluir la sintaxis para los operadores y tal .. algo como esto para un rango de valores

/data/users?age=[30,40] 

o

/data/users?age=>30&age=<40 

haría un poco más fácil de leer, solo asegúrese de codificar en la URL si está usando caracteres reservados