api should have collections for relevant bugs

[Martin Pool]

At the moment to find bugs you must almost always pick a random IHasBugs and then call searchTasks() on it. This works, but is un-restful, not super discoverable, and inconsistent with the rest of the api. It would be good if you could instead say:

  user.affecting_open_bugs_collection_link
  project.open_bugs_collection_link

etc.

For more complicated things you may want to do a search. If https://dev.launchpad.net/LEP/WebservicePerformance is implemented this would fit nicely with its 'restriction' concept, but it would be useful even today.

At the moment these collections exist but are done in the view not the model.

[Robert Collins (lifeless)]

Why do you say its unrestful?

[Martin Pool (mbp)]

Primarily 1- http://en.wikipedia.org/wiki/HATEOAS (great acronym)

> The HATEOAS constraint is an acronym for Hypermedia as the Engine of Application State. This principle is the key differentiator between a REST and most other forms of client server system. Rather than the actions and interfaces a client may use being defined elsewhere, such as in a WSDL file or predefined in the client code, the principle is that the hypermedia in each server response will contain links that correspond to all the actions that the client can currently perform.

So in this case it would be better for eg the person object to point to its assigned bugs, rather than you needing to know you can call a method on the person.

2- Calling a method when a collection link would do just as well is more like rpc than rest.

3- It's inconsistent with the namespace space exposed through the web ui, eg <https://bugs.launchpad.net/~mbp/+assignedbugs>, and generally correspondence is seen as useful in rest.