3 ms·

Hi David, Interesting take on it, your HTTP verbs seem to be pretty well used. I'm not sure that expressing commands with a query string would be very easy to

by thamer 16y ago

Hi David, Interesting take on it, your HTTP verbs seem to be pretty well used. I'm not sure that expressing commands with a query string would be very easy to remember though. The advantage of /COMMAND/ARG0/ARG1.../ARGN is that you can pretty much type a redis command like you do in telnet, replace spaces with slashes, and have an answer. I also maintain the phpredis extension for PHP, and having method names that differed from Redis command names has annoyed people a lot (e.g. lGetRange instead of LRANGE). phpredis now has method aliases with the same name as the underlying Redis command so that users don't have to go back to the documentation all the time. Some people mentioned that GET should always be usable for Javascript apps. It could be interesting to create a list of commands with their respective verb recommendations, and send that recommendation with the response. A strict mode could also for the right verb and disable write commands with GET requests. Thanks for those suggestions!

davidmathers 16y ago
Only LINSERT, LREM, LRANGE, and the blocking commands are expressed using the the query, but I agree that none of them should be. The others are just arguments which have to be arguments in order for the resources to work. Which leads to... Keeping the Redis names means REST isn't even an option. There's no way around that. For instance LINDEX and LSET operate on the same resource, i.e. the same URL. Giving them different URLs means abandoning any and all RESTfulness. This exercise was probably only useful in showing that REST is not what you want, but it was interesting to think about. Thanks for the question!