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.

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.

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.

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.

One benefit is that Javascript can interface with Redis directly through AJAX requests.