sean at basho.com
Wed May 26 13:28:31 EDT 2010
> There was probably a reason for that I am unaware of, so what could
> prevent using the rel element instead of the custom riaktag attribute?
The Link header RFC allows you to create your own attributes to the link. "rel" is a common one that people readily understand (and we use it in a few cases), but separating out riaktag makes it clear that the usage is specific to Riak.
> Also when checking the vclock and etag headers, is it possible to use
> the etag and last modified instead of vclocks at all? I know its
> supported, but still vclock is mandatory now, correct?
The ETag header is a hash of the vector clock, so it is essentially equivalent, but a smaller form. In my mind they serve different purposes - vector clock is for tracking lineage of the object, the etag is for (in)validating caches.
> The meta header could not be contained within the representation
> itself? The http provides meta data in a uniform way, allowing clients
> to extend it at will seems to make it easy to break this interface.
I assume you mean X-Riak-Meta-* headers. These are simple conveniences for the application programmer to express things that don't require interpreting the body of the response. You are free to use them, or not. They have no special meaning from an HTTP perspective, but translate to object metadata in Riak's storage mechanisms.
> Finally, any interest in creating an entry point for it all? Where we
> can navigate to stats, map reduces executed so far and so on?
The challenge of doing such a thing is to enumerate the other endpoints in a way that makes sense from a hypertext perspective. I worry about trying to describe things like /mapred that require POST or buckets and keys that would require expensive listing operations. Any suggestions you have are welcome.
Sean Cribbs <sean at basho.com>
Basho Technologies, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the riak-users