3 ms·

Hi thamer, your question made me curious so I decided to see what I could come up with. I've never used redis so this might be all whack, but here's what I did

Hi thamer, your question made me curious so I decided to see what I could come up with. I've never used redis so this might be all whack, but here's what I did with the list type after looking at the redis docs: Type operations: POST /list?key=<key>&value=<value> -> LPUSH DELETE /list?timeout=<timeout>&key[0]=<key>&key[1]=<key> -> BLPOP List operations: POST /list/<key>?value=<value> -> LPUSHX DELETE /list/<key> -> LPOP Search based operations: POST /list/<key>?find=<value>&value=<value> -> LINSERT BEFORE DELETE /list/<key>?find=<value>&count=<count> -> LREM Index based operations: GET /list/<key>/<index> -> LINDEX GET /list/<key>/<index>?count=<count> -> LRANGE PUT /list/<key>/<index>?value=<value> -> LSET Transactional operations: POST /list-tx/rpop/push?source=<key>&target=<key> -> RPOPLPUSH POST /list-tx/rpop/push?timeout=<timeout>&source=<key>&target=<key> -> BRPOPLPUSH Length GET /list-length/<key> -> LLEN Reverse operations: POST /rlist?key=<key>&value=<value> -> RPUSH POST /rlist/<key>?value=<value> -> RPUSHX DELETE /rlist/<key> -> RPOP POST /rlist/<key>?find=<value>&value=<value> -> LINSERT AFTER DELETE /rlist?timeout=<timeout>&key[0]=<key>&key[1]=<key> -> BRPOP

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!

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!