Hi, I hope I am just missing something… I get an unexpected result when running a basic query with the limit parameter (see API Reference - Omeka S Developer Documentation).
Trying to get a limited number of items (the first 12 in my example), I just run a query like .../api/items?item_set_id=1234&limit=12 but this will return all the items, whereas .../api/items?item_set_id=1234&per_page=12 will return the expected number of items.
How should I use the limit parameter?
Hi @boregar, I could be wrong, but I don’t think the limit parameter is implemented in the REST API endpoint. I took a quick look at the ApiController and I don’t see it applied anywhere.
I think you’ll just have to use per_page.
Thanks Jon! I noticed that the Browse preview block has the same behaviour:
Setting a limit using the Limit input box will work:
whereas setting the limit directly in the Search query will not work:
Do you know 1/ how the limit is applied in first case and 2/ in which case the limit parameter can be used when building a search string?
Hi @boregar ,
Upon examining the Browse Preview block code, it appears that the result of the Search query is not being used to set a limit because it’s always being overwritten by the form value. Even if you don’t set a limit value in the form, a default of 12 will be used.
Ok, thanks Jon, so to my understanding that’s clearly a bug because the value of the limit that may be set during the parsing is never used, right?
@boregar , I think it’s debatable. Where there is a specifically labeled Limit field in the form, it may simply be a design decision and not a bug.
Hi Jon, in this case there should be a warning about the fact that the limit parameter can not be specified in the advanced query string. This means that the search query string does not conform to the documentation.
@boregar, where in the documentation does it say you can use the limit parameter in a search query string? Specifically for the Browse Preview block, I would assume that it would be an option in the query editor if it were intended to function in the search query string and not rely on the Limit field in the form.
I agree that there is a bug in the API (or API documentation) because the limit is not taken into account when it’s specifically mentioned in the docs you pointed to.
Hi Jon, by documentation I mean the developer documentation, this is obviously why I post in the Development section of the forum 
As I did not see an alternative to $view->api()->search(...) to run a search query, I thought that the query string parameters listed in API Reference - Omeka S Developer Documentation were used everywhere a query needs to be built, be it by writing PHP code in a template or by filling a form in the Browse preview block.
I mean, why would it be different?
Pagination is enabled by default in the REST API, meaning that it expects the page and per_page parameters to be used for pagination. If you must use limit, you can force its use by passing and empty page parameter, like ?limit=12&page, but that’s an undocumented feature. Instead, use ?page=1&per_page=12.
Ok, thanks Jim for sharing this “secret” 
I am still a bit confused about the use of the limit parameter: is it or not supported by the PHP API?
The PHP API supports limit. For example, here, the API will return 12 items:
$query = ['item_set_id' => 123, 'limit' => 12];
$items = $api->search('items', $query)->getContent();
Ok, so the parameters shoud be passed as an array and not directly in the query string. Got it!
@boregar , I think you’re confusing the PHP API and the REST API.
Jim is referring to the PHP API and how you would set the limit, and gave an example for that.
You’re original question was regarding the REST API, and you linked to the REST API documentation.
Hi Jon, what is confusing me is the fact that the documentation says that the limit parameter is supported by both API:
… and the fact that the search query string of the Browse preview block is written like a REST API query string:
… and when you debug the query received by the view in the browse-preview.phtml template, it is (correctly) parsed as a PHP API query object:
… but finally the browse preview block does not use the value of the limit parameter.
Examples of how to use correctly the query parameters with both APIs will be appreciated by documentation readers 
I’ll look at adding something to the dev docs to make it clearer that the args you pass to the PHP API are an array, not a string. (edit: actually I think the docs are pretty much okay here already… the PHP API page says that $data is an array, and the reference page you linked notes that pagination “beats” limit and that pagination is default-on for the REST API).
As for Browse Preview, it’s just a browse preview specific thing for that block that we know limiting the number of arguments will be a common use for people, and that the graphical version of the query editor most people will use doesn’t have a limit input, so we have the limit pulled out into a separate input. As a consequence we have that set to override whatever comes in via the query. I don’t think we’re likely to change how that works, but the helper text for Limit should probably be saying that 12 is the default.
Thanks John, that’s cool if you can add something in the dev doc. As for the limit, leaving the Limit text box empty does not respect the hard-coded value of 12: to demonstrate this, simply leave empty the Limit text box:
The debug output of the resources received by the template shows 593 items:
To understand this behaviour, have a look at the Browse Preview block code pointed by Jon in a previous message:
When the text box is empty, the value returned by $block->dataValue('limit', 12) is not 12 but an empty string:
If you look at the code of the dataValue() function, you understand why:
As the $data['limit'] is an empty string and an empty string is not null, the returned value is not $default but an empty string. 
Oh yeah. The 12 fallback will get used only in a rare situation where the Limit box doesn’t get submitted at all, as opposed to being blank.
The helper text therefore correctly doesn’t list a default, in accordance with how the block actually works, but the 12 fallback implies an intention to have a default… we’ll have to just go one way or the other on that. Since the behavior has been to not limit on a blank entry there we’ll probably lean toward keeping it working that way at least for the time being.
Yes, yet it could be a good idea to make sure this is not an oversight
It looks like in this API, limit isn’t applied the way you expect. Using per_page=12 is the correct approach to restrict the number of items returned. limit may be ignored or behave differently depending on the endpoint.
