rest interface

Guilherme Silveira guilherme.silveira at caelum.com.br
Wed May 26 14:17:42 EDT 2010


Thanks for the prompt reply Sean,

> 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.
Most headers will accept extensions, but doing so imply in, i.e., loss
of visibility by intermediates. The rel attribute is a standard and
has the semantic meaning that I tought the riaktag extension want to
express (relations between different buckets?)

> 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.
Yep. Depending on how the user uses it, he might break the interface or not.

> 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
Well, if you are creating a map reduce, you do not need to describe
that it is a POST, the HTTP rfc already did it for us. By simply
creating a link to those resources (i.e. the mapreduce control uri),
the client knows due to the RFC that he has to POST to create
something.

> or buckets and keys that
> would require expensive listing operations.
How are buckets typically accessed? Through URI memorization by the
client when he created them?

Regards

Guilherme Silveira
Caelum | Ensino e Inovação
http://www.caelum.com.br/



2010/5/26 Sean Cribbs <sean at basho.com>:
> Guilherme,
>
> 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>
> Developer Advocate
> Basho Technologies, Inc.
> http://basho.com/
>




More information about the riak-users mailing list