iSheets API version 2 - iSheet module - API - iSheet - advanced search
OVERVIEW
This method is used to get a list of iSheet items.
POST /api/3/isheet/{isheetid}/search?sheetviewid={sheetviewid}&
Parameter Name | Parameter Value | Description |
---|---|---|
isheetid |
|
The ID of the isheet |
sheetviewid |
Optional. Default view will be returned |
|
|
||
|
Request Body
a iSheet item - Advance search - common object
Response Body
a iSheet item - common object - get
Note: As seen in the UI, the response will be shown with iSheet views in the correct sequences.
Andrew Quinn, uhm, sorting locally in JS would not work for me, because it is only client side processing.
Sorting + Paging + Filtering should be returned from the server side.
Ha Nguyen Danh, you would tend to define the sort ordering in the view you are searching against. Especially if it's for a large dataset (>1000) where you will be using paging (limit / offset). If you are having to use an existing view you can't change the order of, then yes you will have to sort locally in JS.
Andrew Quinn I see that this api does not support sorting by column, right?
This API call will return different JSON data structure if there are many records compared to if there is a single result.
If there are many results then they are in an array, as expected.
If there is a single result then there is no array and the item is directly returned, e.g.
No array
`"data": { "item": { "itemid": "123123", ...`
Array
`"data": { "item": [ { "itemid": "123123", ...`
This is non deterministic and not even supported in Swagger 2.0, in the newer OpenAPI spec you could use `oneOf` for this use case.
At any rate, it's very awkward to use this API when it returns different data structures depending on how much data there is.
I would suggest you ONLY return an array, with one result or with many results.
Is âââthere any chance this can be fixed? I am currently forced to call `/{version}/businessWorkflow/isheet/{isheetid}/search` to get the number of records that will be returned, then call the search API with slightly different schemas depending on that first result. This is under Power Apps in azure so there is not much leeway to handle this dynamically.
Also, the search filter data is different for some reason for these two calls.
As I write this I thought to test the XML version of the advanced search, it returns the same data structure in both cases.
I'll try using that as a workaround for now.
Blanca Perez, your only option IS to use this API endpoint (Adv. Search)
Example search request for name of folder, because that's all you can do with advanced search:
{
"data": {
"column": [{
"attributecolumnid": 99999,
Hello Imran Aziz wich is the best way to obtain the itemid of a folder due to update their data?
Mitch Grant some of the swagger documentation was released with Collaborate 5.1 you can get in touch with the support team to enable swagger documentation endpoint for your instance. Once enabled the swagger documentation will be available at the endpoint of https://instanceurl/instancename/showSwaggerUI.action
We have covered the documentation for Site, Users, Groups etc in 5.1 and will be covering Files and some other endpoints in 5.2, the iSheets API endpoints will be covered later on.
We plan to provide more details in a blog post.
Hi Imran Aziz and Jacob Kuhlman, how is the Swagger documentation coming along?
Andrew Quinn thanks for the reminder, I have raised this internally again to get it resolved ASP. Sorry for the delay in getting this sorted.
CC: Amaresh Pandey , Andy Neill
Hi Imran Aziz, can I raise the issue that this endpoint (iSheet Advanced Search) still does not fully work in JSON mode (as of 4.4.6). You can POST JSON data (search criteria), however, the response is always XML regardless of the Accept HTTP header. Thanks in advance, Andrew
Hi Imran, this is especially important if you take into consideration the API Rate Limit functionality. If we are having to make a call to retrieve more details for each of the items in the search results (or any result set), then we will soon hit upon the rate limit for that auth. token. This would be difficult to manage (i.e. wait for limit reset time) when performed in the context of a service, e.g. within an AWS Lambda function, and where that function needs to be atomic in operation, where 'paging' isn't a viable solution. For now, we will need to make sure that all required details are present in the view searched upon so we don't have to perform multiple API calls, but in the future it will be good to have bulk operations for get (isheet items). Thanks, Andrew
Andrew Quinn thank you for the suggestions and explaining the use case as well. I will register them in the API backlog.
Hi Imran Aziz, can I put in a dev request for:
A new admin search API endpoint that does not require a view? The problem is that if you want to retrieve all information about a record, then you either need to create a view with all columns, or make an API call (iSheet - get single) on every record returned from the search results. The problem with creating a view with all columns is making sure that new columns are added to this view when others are creating new columns, and for the other approach merely a performance enhancement.
Another useful enhancement would be extending the iSheet item (get - all items) to accept a request body that contains a list of iSheet itemID's, again to reduce network congestion when retrieving iSheet record data.
Thanks in advance,
Andrew
Comments
13 Comments