The recent change to move to local_site_reverse() broke linking in the web API. Objects were attempting to point to the /api/ tree instead of the /s/{sitename}/api/ tree. This was most noticeable when removing the /api/ tree (for a localsite-only deployment), as it would generate an exception when accessing parts of the API. Fixing this was a simple matter of passing in the request (which contains the localsite info) to local_site_reverse() in WebAPIResource.get_href.

This revealed breakages in the unit tests. For the tests, the URLs were being manipulated to prepend the localsite info, but prepending this to a proper URL resulted in the s/{sitename}/ being in the URL twice. One thing led to another, and I ended up doing a proper cleanup of the URL logic in the unit tests.

Now, instead of making any assumptions about paths (which we did all over the place) we now use local_site_reverse. This is wrapped by get_url or get_item_url/get_list_url functions in the different test classes. These take parameters (parent object and local site name) and construct a proper URL based on that.

The end result is that we are now more shielded when the API tree is in a new place (such as with localsites, or any possible restructuring in the future).

It also cleans things up a bit, as we keep reverse()/local_site_reverse() calls and URL computations to a minimum.

The entire test suite now passes and objects live at their expected places.