launchpad-dev team mailing list archive

[Robert Collins <robertc@xxxxxxxxxxxxxxxxx>]

On Thu, Jun 2, 2011 at 11:48 AM, Martin Pool <mbp@xxxxxxxxxxxxx> wrote:
> The CouchDB book has I think a good description of this denormalizing
> approach near the start, which includes the idea of considering of
> putting into the document what you would expect or want to see in a
> human-oriented web page or paper form about that document: we don't
> make human users go to a different URL to find out about each task on
> a bug, so nor should rest api clients.  I think an API can reasonably
> have an opinion about what makes sense to include by default; then
> later you can perhaps have options about whether or not to include
> things that would be large, expensive, or infrequently used.  If all
> the LP APIs included most of the information shown on the UI pages
> they correspond to, that would be a step forward.

Sadly, couchdb is -not- a shining example of scalability or
performance. We're *still* strugging with a bunch of issues, and at
least for me, their analysis of the problem space is tainted by their
implementation.

Specifically mapping what we show on the UI pages to all the internal
APIs would be a terrible performance disaster. There are *some* APIs
where we will want that. Others we will want to carve the page into
regions and satisfy those through separate APIs.

>>> BTW, lazr.restful is only REST-ish because it defines backdoor function calls.
>>
>> Yes, and this makes me doubt that pure REST is actually a good way to do
>> RPC.  Dirty REST?  Maybe...
>
> I think the good bits of REST are (and they mesh together):
>
>  * think in terms of remote resources that are manipulated, rather
> than remote procedure calls

I'm not sure why this is a good bit for our use case. It is, frankly,
terrible for any complex system. I see lots of nicely done very narrow
very simple RESTish APIs. We may have some of those internally. Its (I
suspect) much more complex to wire up and maintain.

>  * actually use the http verbs, rather than just running everything
> over POST: if you want to just read, just GET
>  * if possible, express things as idempotent or non-mutating
> operations; GET again being a good example

At a semantic level these things are true. But access logs, hot-spot
caching, and just-in-time consistency mean that its extremely limiting
to try and say 'during a GET the server may not perform writes'. Its a
brilliant idea for the cases where you don't need any of those things.
And at least for access logs many folk cheat :).

>  * separate out "what object am I acting on" into the URL; as distinct
> from the parameters of the operation you want to do on it

I've never understood the attraction of this. Exposing things in the
URL is fine, treating the query string as somehow separate doesn't
make any sense.... but perhaps I just have HTTP baked too heavily into
my brain :).

>  * think about the URLs and think about what is transferred on each transaction
>  * the objects are (up to a certain level) self describing and have
> hyperlinks for <http://en.wikipedia.org/wiki/HATEOAS>; I say "up to a
> certain level" because they probably shouldn't include human-oriented
> semantic description

The self describing stuff is *directly* correlated to the terrible
performance of individual collection APIs in Launchpad.

> I think it is a very naïve view of REST to say that each resource must
> be exactly one stand alone application-domain object; it is almost
> guaranteed to perform poorly and there is no point using the name
> "REST" for an architecture that can never work well.

-Rob