2010-12-07 60 views
0

Je travaille sur une application web RESTful. Maintenant, je veux étendre la requête read (GET) pour gérer les requêtes de type SQL mais je n'ai pas été capable de les encoder dans l'URL à cause de tous les caractères spéciaux ("", "/", "<", ">", "{", "}", etc.). J'ai déjà lu que ce n'est pas une bonne idée d'utiliser le corps du message dans une requête GET. Donc pour le moment la seule option que je vois est d'utiliser la requête POST. Mais encore une fois je dirais que ce n'est pas une bonne solution non plus car j'utiliserais POST pour une opération de lecture. Selon les principes REST, la lecture doit être effectuée par la requête GET et le test POST ne doit être utilisé que pour manipuler les données.Application RESTful, envoi d'une requête SQL en lecture

Qu'en pensez-vous? Quel est le meilleur moyen d'envoyer des requêtes de type SQL à mon application Web?

Merci beaucoup

Répondre

2

utilisation CGI :: escape ("select * from NEVER_DO_SUCH_THINGS où Sql_Injection>« dangereux")

+0

Merci. En ce moment j'utilise Python pour envoyer des demandes de test. Cgi.escape de python n'échappe que "<", ">", "&". urllib.quote fonctionne mieux mais n'échappe toujours pas à "/". Cela n'a pas l'air si facile. Par conséquent, je ne suis pas vraiment content de la solution. L'application web devrait fonctionner pour tout le monde et ne dépend pas de la bonne fonction d'échappement, peut-être même d'échapper à la vôtre, etc. – pinky0x51

0

Voir la OData URI Conventions pour un exemple de la façon de bourrer les opérations de requête dans un URI .

Cependant, vous utilisez trop de POST. L'idée des méthodes HTTP est que lorsque les caractéristiques d'une requête correspondent à celles de GET, PUT et DELETE vous DEVRAIT les utiliser. Vous NE DOIT PAS les utiliser si les caractéristiques ne correspondent pas. Cependant, POST est une méthode générique qui peut être utilisée pour n'importe quelle requête.

Le POST ne doit pas obligatoirement écrire, mettre à jour ou manipuler des données de quelque manière que ce soit. En disant à un client qu'il doit utiliser la méthode POST, vous ne faites aucune promesse au client sur le comportement du serveur.

Il n'y a rien de mal à utiliser POST pour soumettre des blocs de données à utiliser pour les requêtes. L'inconvénient est que la réponse d'un POST n'est pas mise en cache et que vous ne pouvez donc pas en profiter.

Il existe de nombreuses approches hybrides, dont POST les paramètres de requête et le serveur crée une nouvelle ressource temporaire qui représente la requête et renvoie ensuite une redirection afin que le client obtienne un get sur la ressource de requête temporaire.