Me gustaría implementar un servicio REST que pueda analizar consultas como recuperar los usuarios creados después de startdate y antes de endate y con el privilegio de admin. Parece que la implementación estándar de REST solo puede realizar consultas por ID. ¿Necesito un protocolo autodefinido para hacer posible este tipo de consulta o cualquier estándar?¿Qué sucede si deseo implementar una consulta complicada en REST
Gracias!
Tome un vistazo a Google's GDATA Protocol. Es muy RESTful y tienen una muy buena forma de realizar consultas "complejas" mientras se mantiene un URI limpio.
http://code.google.com/apis/gdata/docs/2.0/reference.html#Queries
Aquí es un ejemplo de lo que su consulta limpia URIs
http://example.com/jo/-/Fritz/2006
en lugar de
http://example.com/jo?category=Fritz&category=2006
De Google:
Este enfoque identifica un recurso sin tu cantar parámetros de consulta, y produce URI más limpios. Elegimos este enfoque para las categorías porque pensamos que las consultas de categoría serán las consultas más comunes.
Por lo que a mí respecta, las cosas relajantes son válidas para las acciones de CRUD. Puede implementar el método/url search por separado y pasarle tantos parámetros como necesite. Y si todavía intenta adherirse a las metodologías REST, debe usar el tipo de solicitud GET.
> restful stuff es válido para acciones de CRUD. No, no es cierto. – TheWhiteRabbit
@TechExchange tienes razón. Mi conocimiento sobre REST cambió desde que contesté esta pregunta.) – Eimantas
No hay ninguna restricción en REST que diga que solo puede consultar por ID. No hay absolutamente nada de malo en utilizar un conjunto de parámetros de consulta para devolver un conjunto de usuarios que coincidan con esos criterios de búsqueda.
Ryan Bates tiene un Railscast donde muestra la creación de búsquedas como recurso. El concepto aún es válido, incluso si no está haciendo Rails.
Tomo la semántica de las búsquedas de campo de django como las pautas para las búsquedas complejas. https://docs.djangoproject.com/en/dev/ref/models/querysets/#id4
No se deje engañar por el hecho de que se define como una API específica de lanuage, es fácil de traducir a los parámetros de consulta html.
Un ejemplo sería http://example.com/Goods?category=fruit&size__lt=14
para obtener el resultado de select * from goods where category = 'fruit' and size < 14 en SQL o /goods[@category='fruit' and @size < 14] en XPath, o lo que sea.
Creo que es una buena manera, pero no puede satisfacer todas las situaciones. –
Es cierto. Pero te pone en la mentalidad correcta. Los URI deben considerarse ID y no consultas. No piense en su consulta en términos de una cadena de búsqueda o SQL, más bien piense en ello como una ID que identifica un recurso (que a su vez puede ser un conjunto de otros recursos, la hipervinculación es un gran problema en REST). – nategood
Me gustaría diferir.Una * cadena de consulta * en un URI es exactamente con el propósito de consultar. No hace que el enfoque del URI por consulta sea inválido; por el contrario, puede tener ventajas, especialmente en el almacenamiento en caché. Lo mismo ocurre con POSTING una consulta compleja y emitiendo un redireccionamiento. Todo depende de tus necesidades, y ninguna de las soluciones es inherentemente inquietante. – SerialSeb