4 ms·

Webdis: HTTP + JSON API for Redis

55 points by adamstac 16y ago

jpadvo 16y ago
What is the primary practical benefit of this? It seems to simplify doing some really cool things, but I'm not sure what those things are...
- true_religion 16y ago
  To me the main benefit would be that it allows you to plugin other technologies: caching via varnish, proxying va HAProxy, authentication for APIs, etc. because HTTP is well supported. Also, you can access redis via javascript---client or serverside.
- bretthopper 16y ago
  One benefit is that Javascript can interface with Redis directly through AJAX requests.
- geuis 16y ago
  Redis doesn't have a native http interface. Having this kind of interface open all kinds of possibilities for working with Redis. For example, I've been doing some work with Node.js and Redis and one side project I worked on for a while was an http interface. One of the awesome things about CouchDB is its http interface.
- Smrchy 16y ago
  One would be that you can access Redis servers with apps that don't have good / mature Redis clients - like Adobe Coldfusion. Even though you still have to cope with the buggy JSON support in Coldfusion then. But better than no Redis at all i guess.
- thamer 16y ago
  Good question :) I started Webdis because I thought it would be a cool project, after seeing suggestions about such an interface on IRC #redis. Other that the cool factor, the main benefits are IMO: * Javascript clients can access your Redis base. This is already done by CouchDB, on a much larger scale. Webdis is nowhere near such capabilities. * A “Comet” interface to Redis pub/sub commands to stream data using either HTTP chunks (or WebSockets, not implemented yet). * A way to query your Redis server without having to write code. Point your browser to Webdis and see for yourself if the 12th element in that list is what it should be. Having a public interface doesn't mean you have to expose it to your clients, it can be for internal use. * A remote access for heavy clients such as Flash or Air. Webdis already serves a crossdomain.xml file for Flash clients; they can query Redis themselves instead of going though a proxy that you'd have to write by hand. There could be other ways to use it; I'm glad to see the project gain some traction, it will help me figure out what's really important.
  - Mikushi 16y ago
    Very good points. Actually that's something i started doing too with Node.Js, an HTTP interface to Redis for my personal use. At first i did go with a RESTful approach, but you quickly hit the limit of commands available versus the numbers of commands in Redis. The choice i did was the following: Read command are accessed through GET this way: GET http://localhost:8124/get/mykey http://localhost:8124/get/mykey 200 {"mykey" : "mydata"} GET http://localhost:8124/hgetall/mykey http://localhost:8124/hgetall/mykey 200 {"hashKey": {"field1": "value1", "field2": "value2"}} Write commands are run through PUT or POST : POST http://localhost:8124/set/key/value http://localhost:8124/set/key/value 201 {"response": 1} PUT http://localhost:8124/lpush/myList/1 http://localhost:8124/lpush/myList/1 201 {"response": 1} Delete commands through DELETE. DELETE http://localhost:8124/del/mykey http://localhost:8124/del/mykey 200 {"response": 1} DELETE http://localhost:8124/hdel/myHash/field http://localhost:8124/hdel/myHash/field I'm pretty happy with the result, there are some commands i'm not sure where to put though(lpop, rpop, multi, ...)
reshefm 16y ago
Why the wacky SET/GET? Why not being restful and using HTTP verbs?
- antirez 16y ago
  Probably since in Redis there are a multitude of write and read operations, so anyway a good HTTP protocol "map" is not possible.
- eterps 16y ago
  I agree, why on earth would somebody set something with a GET request?
  - jsarch 16y ago
    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.
    - eterps 16y ago
      Hmmm, you're right. The bit about REST and CouchDB is a bit misleading.
- kbd 16y ago
  Because there are a LOT more commands[1] than "set", "get", and "del". http://redis.io/commands http://redis.io/commands
  - eterps 16y ago
    So? REST does not limit the amount of operations you can do on resources.
    - 16y ago
schtono 16y ago
Memcache, for example, is explicitly not meant to be run with "public access", as it is not secured against attacks. I am pretty sure the same applies to redis. If my assumption is correct, i wonder why one should use a (potentially slower) http client or protocol in favor of the "native" protocol.
- eloop 16y ago
  Another use is for obtaining an async redis connection using async http frameworks that may not include a redis client, e.g. tornado. I'm doing something like this at the moment using tornado's async http client talking to a nodejs http server that is basically proxy'ing some simple redis commands.
- antirez 16y ago
  Hello, good point, but I think the idea of the author (accordingly to what I read in the Redis maling list) is to provide some kind of access control list. I think the most interesting practical application of a Redis HTTP interface is accessing your Redis database directly from Javascript. One of such simple ACL is to deny all the commands but the few you use, and use unguessable key names. This is good for a low level of security. There are of course much better ways... but I'm curious about how this could evolve.
- thamer 16y ago
  (I'm the author of Webdis) As antirez pointed out, there are indeed ACLs in Webdis. You can enable or disable commands using a CIDR match and/or HTTP Basic Auth. (ex: disable all write commands for everyone, but enable SET for authenticated clients on the local network).
jcromartie 16y ago
This is also called "CouchDB."
deleted 16y ago
[deleted]
delano 16y ago
There's also Bone which implements SET, GET, and KEYS over HTTP(S). It also uses something similar to the Amazon S3 request signatures for authentication. https://github.com/solutious/bone https://github.com/solutious/bone

55 points by adamstac 16y ago

What is the primary practical benefit of this? It seems to simplify doing some really cool things, but I'm not sure what those things are...

true_religion 16y ago
To me the main benefit would be that it allows you to plugin other technologies: caching via varnish, proxying va HAProxy, authentication for APIs, etc. because HTTP is well supported. Also, you can access redis via javascript---client or serverside.
bretthopper 16y ago
One benefit is that Javascript can interface with Redis directly through AJAX requests.
geuis 16y ago
Redis doesn't have a native http interface. Having this kind of interface open all kinds of possibilities for working with Redis. For example, I've been doing some work with Node.js and Redis and one side project I worked on for a while was an http interface. One of the awesome things about CouchDB is its http interface.
Smrchy 16y ago
One would be that you can access Redis servers with apps that don't have good / mature Redis clients - like Adobe Coldfusion. Even though you still have to cope with the buggy JSON support in Coldfusion then. But better than no Redis at all i guess.
thamer 16y ago
Good question :) I started Webdis because I thought it would be a cool project, after seeing suggestions about such an interface on IRC #redis. Other that the cool factor, the main benefits are IMO: * Javascript clients can access your Redis base. This is already done by CouchDB, on a much larger scale. Webdis is nowhere near such capabilities. * A “Comet” interface to Redis pub/sub commands to stream data using either HTTP chunks (or WebSockets, not implemented yet). * A way to query your Redis server without having to write code. Point your browser to Webdis and see for yourself if the 12th element in that list is what it should be. Having a public interface doesn't mean you have to expose it to your clients, it can be for internal use. * A remote access for heavy clients such as Flash or Air. Webdis already serves a crossdomain.xml file for Flash clients; they can query Redis themselves instead of going though a proxy that you'd have to write by hand. There could be other ways to use it; I'm glad to see the project gain some traction, it will help me figure out what's really important.
- Mikushi 16y ago
  Very good points. Actually that's something i started doing too with Node.Js, an HTTP interface to Redis for my personal use. At first i did go with a RESTful approach, but you quickly hit the limit of commands available versus the numbers of commands in Redis. The choice i did was the following: Read command are accessed through GET this way: GET http://localhost:8124/get/mykey http://localhost:8124/get/mykey 200 {"mykey" : "mydata"} GET http://localhost:8124/hgetall/mykey http://localhost:8124/hgetall/mykey 200 {"hashKey": {"field1": "value1", "field2": "value2"}} Write commands are run through PUT or POST : POST http://localhost:8124/set/key/value http://localhost:8124/set/key/value 201 {"response": 1} PUT http://localhost:8124/lpush/myList/1 http://localhost:8124/lpush/myList/1 201 {"response": 1} Delete commands through DELETE. DELETE http://localhost:8124/del/mykey http://localhost:8124/del/mykey 200 {"response": 1} DELETE http://localhost:8124/hdel/myHash/field http://localhost:8124/hdel/myHash/field I'm pretty happy with the result, there are some commands i'm not sure where to put though(lpop, rpop, multi, ...)

reshefm 16y ago

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

antirez 16y ago
Probably since in Redis there are a multitude of write and read operations, so anyway a good HTTP protocol "map" is not possible.
eterps 16y ago
I agree, why on earth would somebody set something with a GET request?
- jsarch 16y ago
  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.
  - eterps 16y ago
    Hmmm, you're right. The bit about REST and CouchDB is a bit misleading.
kbd 16y ago
Because there are a LOT more commands[1] than "set", "get", and "del". http://redis.io/commands http://redis.io/commands
- eterps 16y ago
  So? REST does not limit the amount of operations you can do on resources.
  - 16y ago

schtono 16y ago

Memcache, for example, is explicitly not meant to be run with "public access", as it is not secured against attacks. I am pretty sure the same applies to redis. If my assumption is correct, i wonder why one should use a (potentially slower) http client or protocol in favor of the "native" protocol.

eloop 16y ago
Another use is for obtaining an async redis connection using async http frameworks that may not include a redis client, e.g. tornado. I'm doing something like this at the moment using tornado's async http client talking to a nodejs http server that is basically proxy'ing some simple redis commands.
antirez 16y ago
Hello, good point, but I think the idea of the author (accordingly to what I read in the Redis maling list) is to provide some kind of access control list. I think the most interesting practical application of a Redis HTTP interface is accessing your Redis database directly from Javascript. One of such simple ACL is to deny all the commands but the few you use, and use unguessable key names. This is good for a low level of security. There are of course much better ways... but I'm curious about how this could evolve.
thamer 16y ago
(I'm the author of Webdis) As antirez pointed out, there are indeed ACLs in Webdis. You can enable or disable commands using a CIDR match and/or HTTP Basic Auth. (ex: disable all write commands for everyone, but enable SET for authenticated clients on the local network).

jcromartie 16y ago

This is also called "CouchDB."

deleted 16y ago

[deleted]

delano 16y ago

There's also Bone which implements SET, GET, and KEYS over HTTP(S). It also uses something similar to the Amazon S3 request signatures for authentication. https://github.com/solutious/bone https://github.com/solutious/bone