However, I accept that this might not be optimal for a couple of reasons:
- It requires a separate call to the index
- It requires pagination support on the client
The second point can be mitigated by adjusting the size parameter accordingly to get things off the ground, but that's a temporary work-around - ultimately, the scope is going to have to support pagination, otherwise we'll be returning potentially thousands of results in a single response. It's not just the network usage that's a problem here, but the memory and processing overhead on the client.
The first point can be addressed on the server side by embedding clickindex:package resources in the department response. This is, in fact, the long-term plan. There was an unfortunate mix-up in terminology that led to "browsing search results by department" being misinterpreted as "browsing for arbitrary packages by department" - the former of which is not currently supported, the latter being expressly permitted - and so this embedding was de-scoped for RTM. I'm happy to do the work to support it now, with the caveat that pagination support will be added later.
This is already possible via the search API:
{ /search. apps.ubuntu. com/api/ v1/search? q=department% 3A%22games% 22&page= 1&size= 2" /search. apps.ubuntu. com/api/ v1/search? q=department% 3A%22games% 22&page= 35&size= 2" /search. apps.ubuntu. com/api/ v1/search? q=department% 3A%22games% 22&page= 2&size= 2" /search. apps.ubuntu. com/api/ v1/search? q=department% 3A%22games% 22&page= 1&size= 2"
"templated" : true, /search. apps.ubuntu. com/docs/ relations. html{#rel}" :recommendation ": [], :package" : [ /myapps. developer. ubuntu. com/site_ media/appmedia/ 2013/09/ solitaire- games64. png", developer. labsin. solitaire- games", /search. apps.ubuntu. com/api/ v1/package/ com.ubuntu. developer. labsin. solitaire- games"
"publisher" : "Sam Segers", /myapps. developer. ubuntu. com/site_ media/appmedia/ 2014/06/ rockpaperscisso rslogo_ 256.png", developer. 11ubuntucg. rockpaperscisso rs", /search. apps.ubuntu. com/api/ v1/package/ com.ubuntu. developer. 11ubuntucg. rockpaperscisso rs"
"publisher" : "Brian Jaury",
"_links": {
"first": {
"href": "https:/
},
"last": {
"href": "https:/
},
"next": {
"href": "https:/
},
"self": {
"href": "https:/
},
"curies": [
{
"name": "clickindex",
"href": "https:/
}
]
},
"_embedded": {
"clickindex
"clickindex
{
"price": 0,
"icon_url": "https:/
"title": "Solitaire Games",
"name": "com.ubuntu.
"_links": {
"self": {
"href": "https:/
}
},
"content": "application"
},
{
"price": 0,
"icon_url": "https:/
"title": "Rock Paper Scissors",
"name": "com.ubuntu.
"_links": {
"self": {
"href": "https:/
}
},
"content": "application"
}
]
}
}
However, I accept that this might not be optimal for a couple of reasons:
- It requires a separate call to the index
- It requires pagination support on the client
The second point can be mitigated by adjusting the size parameter accordingly to get things off the ground, but that's a temporary work-around - ultimately, the scope is going to have to support pagination, otherwise we'll be returning potentially thousands of results in a single response. It's not just the network usage that's a problem here, but the memory and processing overhead on the client.
The first point can be addressed on the server side by embedding clickindex:package resources in the department response. This is, in fact, the long-term plan. There was an unfortunate mix-up in terminology that led to "browsing search results by department" being misinterpreted as "browsing for arbitrary packages by department" - the former of which is not currently supported, the latter being expressly permitted - and so this embedding was de-scoped for RTM. I'm happy to do the work to support it now, with the caveat that pagination support will be added later.