Quelle est la meilleure façon de créer des requêtes complexes RESTful?

Question

Quelle est la meilleure façon de récupérer des requêtes complexes à partir d'un service REST? Supposons que je veux obtenir des collections X, appliquer des filtres et des équations à chacun d'eux, combiner les collections en utilisant une autre opération et retourner un résultat, tout en une seule requête.

Il est juste trop complexe (et gros) de tout mettre dans la chaîne de requête car je pourrais combiner plus de 300 collections (plus les opérateurs et les filtres à chacun).

Je pensais à l'aide de POST pour envoyer un objet XML décrivant la requête à quelque chose comme:

http://mydomain/collections/complexQuery 

Il retourneraient un identifiant unique et alors je pourrais utiliser GET pour récupérer le résultat complexQuery:

http://mydomain/collections/complexQuery/{queryId} 

Jason S:

Voilà l'idée. Le POST prendra une représentation XML de la requête, avec déjà les paramètres "where" (ils peuvent être trop nombreux). La requête ne sera exécutée que lorsque le GET arrivera. Je pourrais laisser l'objet de requête disponible juste pour quelque temps et le supprimer plus tard.

Est-ce une bonne solution? Suis-je encore RESTful faire cela?

Answer 1

Sonne RESTful pour moi si vous utilisez un identifiant unique. Si le jeu de résultats de la requête est grand, vous pouvez inclure un moyen de demander des lignes de jeu de résultats M - N où M, N sont des paramètres.

Je suppose qu'un avantage de votre approche d'ID unique (avec l'état de définition de requête stocké sur le serveur) est que vous pouvez utiliser le résultat de la requête en tant que paramètre d'une autre requête. Peut-être même séparer POST la définition d'une requête de l'exécution de la requête.

Answer 2

Ceci est l'approche RESTful standard. POST à la ressource et attendez un 201 Created (aucun corps d'entité) avec l'URI aux résultats créés dans l'en-tête Location. Vous pouvez également renvoyer les résultats avec une réponse 200 OK et, facultativement, un URI pointant vers les résultats pour la référence future (de) dans la réponse avec une copie des résultats.

Answer 3

C'est OK. Mais il introduit quelques problèmes:

1. Vous devez conserver les données de requête sur le serveur, quand nettoyez-vous les anciennes requêtes?

2. Si vous nettoyez les anciennes requêtes, cela signifie que vous ne pouvez pas fournir de liens vers des requêtes enregistrées car elles ont peut-être déjà été nettoyées.

3. Même requête simple nécessite deux allers-retours (POST & puis GET)

4. Votre client a besoin d'être familier avec le schéma XML que vous attendez, au lieu du bien connu: param1=val1&param2=val2

Answer 4

désolé, mon ignorance ...

mais pourquoi ne pas simplement retourner les données avec le poste ???

Je peux comprendre pourquoi il est erroné de mettre à jour les données avec un get, mais je ne vois pas pourquoi il devrait être obligatoire de mettre à jour les données à chaque poste? Je comprends également que l'idée est que chaque méthode get peut être potentiellement mise en cache (car elle ne modifie pas les données), mais dans ce cas elles ne peuvent être mises en cache que si la requête sauvegardée temporairement est toujours active ... ajoute une autre couche de complexité ...

Je pensais aussi que l'un des principes de repos est de définir des interfaces sans état (comme le protocole http), et dans ce cas le serveur maintient un état pour résoudre la requête. .

Je viens juste de commencer la lecture de repos et il zone plusieurs choses que je ne comprends pas encore ...