launchpad-dev team mailing list archive

[Jonathan Lange <jml@xxxxxxxxxxxxx>]

On Mon, Mar 29, 2010 at 3:34 PM, James Westby <jw+debian@xxxxxxxxxxxxxxx> wrote:
> 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.
>

I think ultimately you'll need to be explicit. For example,
IBranchTarget(sourcepackage).name != sourcepackage.name for any
ISourcePackage.

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

There are interfaces which are adapted to that have writeable
properties which change the database when written to.

Even if there weren't any that existed now, I think it would be
misguided to constrain our object model to make the webservice
implementation easier.

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

I'd lean to the second – to being explicit. The atomicity concerns
would not be unique to adapted objects.

Thanks for the thoughtful reply.
jml