rest interface

Sean Cribbs sean at basho.com
Wed May 26 18:01:35 EDT 2010


On May 26, 2010, at 2:17 PM, Guilherme Silveira wrote:

> 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?)
> 

If the intermediate is well-behaving, it should either not care about the header, or understand it and deal accordingly.   There's nothing in the RFC that requires the tag to be of one of the default types.  If we used 'rel', there might be unintended meanings introduced simply by an application's domain-specific use of the tag.  Keeping it separate avoids those issues.

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

How would it "break the interface"? Do you mean that they would lose data?  If your clients have no knowledge that they are performing writes to Riak, then your application shouldn't use the headers.  That's why they're X- headers, indicating that they are non-standard and application-specific.

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

Maybe I misunderstand you.  How would you envision a generic endpoint?

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

Yes, you need to know what buckets your application is using.  Most applications use a limited number of buckets or have deterministic ways to compute their names, so this is not generally an issue.

In general, while Riak (via Webmachine) attempts to conform to the HTTP 1.1 spec, it is first and foremost a database, and so there were some practical decisions made that might not fit the purist's worldview.  The standards we try to meet are:

1) Do we handle the hard parts of HTTP well (e.g. content-negotiation, appropriate response codes)?
2) Do we behave predictably when integrated in larger HTTP infrastructures (with load-balancers, caches, etc)?

I believe we meet those.

Sean Cribbs <sean at basho.com>
Developer Advocate
Basho Technologies, Inc.
http://basho.com/






More information about the riak-users mailing list