Les inconvénients de la prise en charge des conditions de requête génériques dans les API REST?

Question

Je voudrais savoir quels sont les compromis de l'API REST supportant une grande variété de contraintes de requête. Je pense à ce que fait une API like that of Parse.

Parse sur REST permet de construire presque entièrement une instruction DB sur le client, et j'imagine que sur le serveur ils ont un moteur qui traduit la clé where: {} JSON en une requête Mongo correcte qui inclut tous les conditions définies. Par exemple, voici quelque chose qu'on pourrait faire:

curl -X GET \ 
    -H "X-Parse-Application-Id: xxx" \ 
    -H "X-Parse-REST-API-Key: xxx" \ 
    -G \ 
    --data-urlencode 'where={"hometown":{"$select":{"query":{"className":"Team","where":{"winPct":{"$gt":0.5}}},"key":"city"}}}' \ 
    --data-urlencode 'limit=200' \ 
    --data-urlencode 'skip=400' \ 
    https://api.parse.com/1/classes/_User 

Comme vous pouvez le voir dans la section de données, on pourrait générer des requêtes assez complexes et intéressantes sur le client en utilisant ce système très flexible. Maintenant supposons que vous n'êtes pas Parse, vous utilisez SQL, et votre exigence (privée!) De l'API n'est pas de supporter tous les types imaginables de requêtes qu'un client peut faire, mais vous pourriez toujours bénéficier de la possibilité de définir quelques contraintes ici et là pour éviter d'envoyer au client des données qu'il n'utilisera pas, simplement parce qu'il ne peut pas définir une requête avec une précision suffisante.

L'approche du moteur de génération d'instructions DB est-elle simplement trop lourde dans le cas ci-dessus? Si c'est le cas, comment gérer les différentes ressources (limite, saut, commande), mais pas toutes? Certains pourraient être spécifiques à cette ressource. Toutes les bonnes ressources qui parlent des différentes décisions de conception ici?

Answer 1

Si vous souhaitez une architecture RESTful, vous devez utiliser HATEOAS, ce qui signifie que les requêtes doivent être générées en fonction des représentations envoyées dans les réponses précédentes. Un "moteur de génération d'instructions DB" est donc inutile, car toutes les options qui peuvent être définies seront fournies en tant que modèle par le serveur (par exemple un formulaire HTML, mais probablement quelque chose de plus complexe dans votre cas, peut-être XForms dans un type de contenu personnalisé). Les contraintes seront définies par le balisage d'entrée de formulaire. Choisissez un langage de balisage suffisamment adéquat pour décrire toutes vos contraintes au client.