Hacker News Reader

Comment by reshefm | Hacker News Reader

Why the wacky SET/GET? Why not being restful and using HTTP verbs?

(I'm the author of Webdis)

I agree with you, and to be honest this is what bothers me the most in the current state of the project. The top point in the list of TODO/IDEAS is currently “Add better support for PUT, DELETE, HEAD, OPTIONS? How? For which commands?”.

I'd be very glad to hear about a better way to implement this. As antirez (author of Redis) and kbd pointed out, Redis supports a lot more than GET/SET. How do I make LPUSH/RPUSH/SADD... RESTful?

why SET, maybe POST?

I think any command that modifies and writes to the DB should be POST or PUT (for editing existing entries), what reads should be GET and anything that delete should be DELETE?

Please please please do not make the API dependent on HTTP method verbs. This completely breaks JavaScript apps[1] and it's an arbitrary constraint that does not benefit anything except REST zealotry.

[1] For example, cross-domain JavaScript requests can only read GET responses.

I think there should be a way to disable GET for some commands, this seems to be a serious concern. That said, you'll always be able to access Webdis using GET; you present a common case that justifies the existence of such a feature.

I have started to implement Cross-Origin Resource Sharing, which should enable cross-domain JS requests using POST (If I understood correctly). An OPTIONS call is made by the client before the POST.

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

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!

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!

Probably since in Redis there are a multitude of write and read operations, so anyway a good HTTP protocol "map" is not possible.

Because there are a LOT more commands[1] than "set", "get", and "del".

http://redis.io/commands

So? REST does not limit the amount of operations you can do on resources.

You must've misread somewhere. The OP said "Why not being restful and using HTTP verbs?" I said "because there are far more commands than HTTP verbs".

In other words, this has nothing to do with "the amount of operations you can do with rest", this has to do with not being able to use the limited number of HTTP verbs to correspond to the multitude of Redis commands.

I agree, why on earth would somebody set something with a GET request?

If you separate the syntax from the semantics, you'll see that the GET request (syntax) is merely the mechanism of accessing the appropriate function (semantics). If you reread the short article after deleting all the junk about REST and CouchDB, and ignore the presumption that this is a RESTful API, then the article is clearer: Webdis is an HTTP interface to Redis.

Hmmm, you're right. The bit about REST and CouchDB is a bit misleading.

Reply on news.ycombinator.com