Add web_link property to resources

Bug #316694 reported by Gavin Panella on 2009-01-13
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Launchpad itself
Leonard Richardson
Leonard Richardson

Bug Description

It would be useful to be able to get the link to a human-readable
representation of an API object. The transformation is relatively

Leonard Richardson wrote:
> ... you can replace '/api/[^/]*/' with ''. We've determined that
> that's always the relationship between the web service canonical_url
> and the browser canonical_url.

It makes sense to add a method or property to API objects that does
just this.

Related branches

Markus Korn (thekorn) wrote :

yes, having such a method for recources would be really cool, I'm using something similiar to
   url = self_url.replace("api.", "").replace("beta/", "")
very often.

Changed in launchpadlib:
status: New → Confirmed
Changed in launchpadlib:
importance: Undecided → High
status: Confirmed → Triaged
William Grant (wgrant) wrote :

Isn't this rather a lazr.restful feature request?

Francis J. Lacoste (flacoste) wrote :

Since the rule to derive the web url from the resource URL are fixed, it makes sense to implement this on the client side in a convenient method instead of bloating the representation.

Martin Pool (mbp) wrote :

Is it really guaranteed this relationship will always be the same? If not, maybe it should be in the server.

Anyhow, for those using Markus's code, note that the thing you start from is typically 'self_link' not 'self_url'.

Martin Pool (mbp) wrote :

For those copy-and-pasting, the change will be somewhat safer as

launchpad_object.self_link.replace('api.', '', 1).replace('/beta/', '/', 1)

Leonard Richardson (leonardr) wrote :

This is about to change, if I ever manage to land the multi-version branch. The self_link will no longer start with '/api/beta/', but instead will start with '/api/devel/'.

On 17 February 2010 23:25, Leonard Richardson
<email address hidden> wrote:
> This is about to change, if I ever manage to land the multi-version
> branch. The self_link will no longer start with '/api/beta/', but
> instead will start with '/api/devel/'.

That sounds like a really good reason to put the .web_url code into
Launchpadlib, because that change will break most launchpad client

Leonard Richardson (leonardr) wrote :

Sorry, I thought we were talking only about Launchpad Ajax here. We're changing the Launchpad web site so that instead of making requests to /beta/ it makes requests to /devel/, which of course makes the URLs have /devel/ in them. If you've got a launchpadlib program you can continue to make requests to /beta/ and the URLs will continue to have /beta/ in them.

However, I agree that the .web_url should be provided as part of the representation.

Francis J. Lacoste (flacoste) wrote :

Should it really be part of the representation? Why not implement it in the client-side API.

Leonard Richardson (leonardr) wrote :

On Thu, 2010-02-18 at 15:36 +0000, Francis J. Lacoste wrote:
> Should it really be part of the representation? Why not implement it in
> the client-side API.

Because the implementation changes. If we had already implemented it in
the client-side API, our implementation would become incomplete when I
land the multi-version branch. Implementing URL generation on the server
lets us change it however we want. Especially because the trend is for
the implementation to become more complex over time.

I don't believe that this is an incredibly powerful argument here,
because it's unlikely this implementation will _keep_ changing or become
_very_ complex, but this is why we send links in general instead of
defining rules and having the clients implement those rules.

Gary Poster (gary) wrote :
Tim Penhey (thumper) on 2011-01-22
affects: launchpadlib → lazr.restful
Changed in lazr.restful:
status: Triaged → In Progress
assignee: nobody → Leonard Richardson (leonardr)
Changed in launchpad:
status: New → In Progress
importance: Undecided → High
assignee: nobody → Leonard Richardson (leonardr)
tags: added: api
Launchpad QA Bot (lpqabot) wrote :
tags: added: qa-needstesting
Changed in lazr.restful:
status: In Progress → Fix Committed
tags: added: qa-ok
removed: qa-needstesting
Martin Pool (mbp) wrote :
William Grant (wgrant) wrote :

This is now deployed, but I can't see it directly in launchpadlib without going through the WADL resource.

Changed in launchpad:
status: In Progress → Fix Released
Gavin Panella (allenap) wrote :

Fwiw, rm -r ~/.launchpadlib/*/cache got it working for me.

William Grant (wgrant) wrote :

Huh, indeed. Perhaps there was some WADL cached inappropriately.

Leonard Richardson (leonardr) wrote :

The WADL will be cached for a week. I filed bug 714621 to reevaluate our caching strategy in light of our new continuous deployment.

Changed in lazr.restful:
status: Fix Committed → Fix Released
Martin Pool (mbp) wrote :

I had cache problems with this too, much more than a week after this was landed. See bug 752107.

Dave Walker (davewalker) wrote :

I am still seeing this issue in current oneiric, using launchpadlib via requestsync.


Martin Pool (mbp) wrote :

Dave, can you please post some small example code?

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers