launchpad-dev team mailing list archive

[James Westby <jw+debian@xxxxxxxxxxxxxxx>]

On Mon, 29 Mar 2010 13:48:48 +0100, Jonathan Lange <jml@xxxxxxxxxxxxx> wrote:
> This is the right solution given our current constraints, but it's kind of ugly.
> 
> I know there's a bunch of stuff to do with the webservice API first,
> but do we have any idea how we can have methods on interfaces where
> they make sense and still expose them over the webservice API?

I don't think adapters can be exposed to the client as adapters, as they
would require a canonical URL, where they don't really have one.

Therefore we need to annotate the objects to state that they can be
adapted by, e.g. IBranchTarget, and then have the wadl generation and
JSON representation code include those methods/attributes that are
exported on the adapter.

When the webservice received a method call on the object it could then
either infer what adapter is needed to get the object to call the actual
method on, or this could be a fixed parameter to the method call:

  ?ws.op=newCodeImport&ws.adapter=lp.code.interfaces.branchtarget.IBranchTarget

so that fewer smarts were needed.


We could give the adapted objects a canonical URL subordinate to the
concrete objects. Then when you GET a branch URL you would see

   {
   ...
   branch_target_link: <branch-url>/+branch-target
   ...
   }

and you can then GET branch_target_link to see the attributes of the
adapted object, or POST to it to call a method.

I'm not sure how this would be declared in the code though.

One of the differentiators is how PATCH requests would work. Are there
any adapted objects that would have DB references?

If there are writeable attributes in any adapted objects then you have
the choice between a PATCH to the object and it's adapted version that
would have to infer which attributes are associated with which object,
or two PATCH requests with the inherent atomicity concerns.

Thanks,

James