
Webdis: HTTP + JSON API for Redis - adamstac
http://thechangelog.com/post/2910383164/webdis-a-redis-http-interface-with-json-output
======
schtono
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.

~~~
antirez
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.

------
jpadvo
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...

~~~
thamer
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
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>

200 {"mykey" : "mydata"}

GET <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>

201 {"response": 1}

PUT <http://localhost:8124/lpush/myList/1>

201 {"response": 1}

Delete commands through DELETE.

DELETE <http://localhost:8124/del/mykey> 200 {"response": 1}

DELETE <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
Why the wacky SET/GET? Why not being restful and using HTTP verbs?

~~~
thamer
(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?

~~~
shazow
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.

~~~
thamer
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.

------
delano
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>

------
jcromartie
This is also called "CouchDB."

