How does Redis fit into ASP.NET Web API OData world?

Question

If you think about a large-scale solution where you've a second-level cache implemented using Redis or maybe your first data source is also Redis, I don't find how ASP.NET WebAPI OData implementation can work together with something like a key-value store.

I could analyze generated expression tree by the OData parser and translate some filters into Redis operations, but the whole nature of Redis fits best when you implement pure REST:

• http://somesite.com/users => users (Redis set)
• http://somesite.com/users/1 => users:11 (Redis key)

And if I want latest registered users, maybe I would have something like this:

• http://somesite.com/users/latest => users:latest (Redis sorted set)

The whole question...

What has to do OData in such scenario?

Answer 1

I think Redis can be very useful in an OData environment. I think first I'd address a perception issue: that OData isn't "pure REST". REST, of course, can mean many things since there's very little standard for it. For the most part, REST has come to mean JSON over HTTP/S using standard HTTP verbs mapped to operations on entities. OData simply takes this, adds some more formal definition to it, and adds a standard metadata layer to it (which you can choose to ignore if you want). Because of this I have come to referring to OData as "JSON++". I don't think I've seen an OData implementation that doesn't support JSON, though many defualt to Atom if JSON isn't specified. So, when interacting with OData with JSON - is there anything that isn't "Pure REST" about this?

So, that said, I see two interesting ways to interact with Redis in an OData world. It would be possible, even interesting, to build an OData front end to Redis. That wouldn't be trivial I suppose, but it should be possible. I'm not aware of anybody doing this, but there may be. There is an OData provider for Node.js for example, maybe somebody has done something for Redis.

But even using stock Redis, it should just be a matter of using OData URLs as redis keys (which you seem to be leaning toward anyway)- caching results at the query level. This seems to be what you were illustrating in your example. Since you are caching data, you may want to manage the lifetime of cached results using the EXPIRE command after inserting an entry. If you want to get really fancy you can look at strategies to pre-populate the redis cache.

You mentioned the possibility of a more granular use of redis- thus requiring that you parse queries etc. You could, of course, use the redis cache at the entity level and fully implement all of Odata on top of it. Personally, I'm not sure this is worth the complexity. I like the idea of using redis at the granularity of query results.

The short answer to your question: Anything you can do with REST/JSON+Redis, you can accomplish with OData+Redis. Value prop is the same.