I use a GET request with the following url to retrieve data from a sharepoint list:
https://graph.microsoft.com/v1.0/sites/{site_id}/lists/{list_id}/items?expand=fields
However, in the value-key of the response dict i get only 200 entries. The List has roughly 250 entries.
So I guess microsoft graph api has some limitation on how many samples can be requested from the endpoint at once.
I cannot find anything in the doc (https://learn.microsoft.com/en-us/graph/api/listitem-list?view=graph-rest-1.0&tabs=http) on how I could get the missing entries.
Any clues?
If the request does not contain all elements the json response contains a key #odata.nextLink.
a get request on that link gives you the next 200 entries in the list
Related
I am trying to get list of user paginated
I tried work with this endpoint
GET /admin/realms/{realm}/users
but the response contain all the user.
Endpoint GET /admin/realms/{realm}/users supports pagination (look at method source code)
Just add query params first & max to your request. For example:
/auth/admin/realms/<your realm>/users?briefRepresentation=true&first=0&max=5
P.S. Total records count will be returned in response headers
I want download WIQL report using REST API. REST response doesn't give all fields but it gives a list of URLS as workItems.
To get field values I need to download each WorkItem separately.
Any direct REST way to accomplish this in a single REST call?
Repeated REST calls gives me rate limiting or similar error. I get error 500 types after repeated GET request.
Genesis of this need is - There are no aggerate functions available likes of SUM, MAX, MIN, AVG Etc.
REST response doesn't give all fields but it gives a list of URLS as
workItems.
To get field values I need to download each WorkItem separately. Any
direct REST way to accomplish this in a single REST call?
Sorry but as I know, there's no direct rest api available to get WIQL report. An alternative workaround should be:
1.Use Query By Wiql to return the list of WorkItem IDs and Urls (I think this is the same rest api you use).
2.Then use Get Work Items Batch to get all the details(fields) about the requested work item ids. And here's one issue which has similar needs like yours, you can use the upgraded script from konpro11 to get list of IDs and use the IDs to get your report (with the help of second rest api).
Hope it helps :)
I'm trying to retrieve all the playlists from my account via
http://api.soundcloud.com/users/145295911/playlists?client_id=xxxxxx, as the API reference shows.
However, I can only retrieve recent 50 playlists instead of all of my playlists. I've been looking for this but it seems like no one has had this issue before. Is there a way to get all of them?
Check out the section of their API on pagination.
Most results from our API are returned as a collection. The number of items in the collection returned is limited to 50 by default with a maximum value of 200. Most endpoints support a linked_partitioning parameter that will allow you to page through collections. When this parameter is passed, the response will contain a next_href property if there are additional results. To fetch the next page of results, simply follow that URI. If the response does not contain a next_href property, you have reached the end of the results.
I can't get Facebook to return the page like count, the response provided does not match what the API states. According to the docs, the following URL:
https://graph.facebook.com/v2.10/<page-id>/likes?access_token=<access-token>&summary=true
should return a JSON response with a summary key that provides the like count in the corresponding hash. The problem is the response never contains the summary key, but it does contain the data and pager keys as specified in the docs.
I'm certain my access token is valid and my page ID are correct.
I've also tried to get the page_fans metric from the page insights via the following URL, but it simply returns an empty data object.
https://graph.facebook.com/v2.10/<page-id>/insights/page_fans?access_token=<access-token>
Is there another way to go about retrieving the like count for a page or any particular reason that the requests would succeed, but be missing the relevant data?
Facebook Doc Links:
https://developers.facebook.com/docs/graph-api/reference/v2.10/object/likes
https://developers.facebook.com/docs/graph-api/reference/v2.8/insights
UPDATE
I was able to retrieve the count by using this Graph API call:
https://graph.facebook.com/v2.10/<page-id>?access_token=<access-token>&fields=engagement
As New Hand pointed out, you can get the key directly, without going through the engagement field using the following:
https://graph.facebook.com/v2.10/<page-id>?access_token=<access-token>&fields=fan_count
Do you mean to get the fan_count?
Please try this:
https://graph.facebook.com/v2.10/<page-id>?access_token=<access-token>&fields=fan_count
I am designing a REST like API for paginated data retrieval of a YUI-based client.
The REST URL looks like this for a GET request:
/app/catalog/data?startIndex=<int>&results=<int>&sort=<sting>&dir=<string>
All parameters are optional, i.e. if no parameters are given, all data from DB will be dumped.
Now say that there are only 1000 records in the database. Following reqeust is made:
/app/catalog/data?startIndex=1100&results=25
What status code should I return if the paginated result from the database remains empty though the request was fine?! I can't decide whether this is 204 or 404.
The produced media types are JSON and CSV.
I would say 204 is most appropriate. The request was successful, just with no results.
10.2.5 204 No Content
The server has fulfilled the request but does not need to return an entity-body, and might want to return updated metainformation.
Sounds exactly like the case.
I can't decide whether this is 204 or 404.
Neither. Just return 200 with an empty result (empty XML document or JSON array, whatever you use). Typically I use REST services with paginated views so along with results page I return total number of records. This will help clients to realize the mistake. But technically it is nothing wrong.
Use 204 for DELETE operations (there's really no content to return) and for PUT.
BTW (bold mine):
if no parameters are given, all data from DB will be dumped
Believe, you don't want to do this...
What format do you normally return your results in? I'd be inclined to make this 204 or even 200 returning an empty list.
HTTP 204 in pagination response is not factible because of the payload. When paginating you should return pagination information like, items returned, total items, offset, etc. which makes no sense with HTTP 204.
HTTP 204 is useful on resource updates (ie PUT) when you want to explicitly say that the resource does not need to be fetched again (GET). For example, resources that have calculated fields and require a refresh of the view after every update, fetching those calculated fields from the server. Therefore, the 204 status code has specific use cases and must be designed and documented.
I would use one of:
HTTP 200 with count=0 and no items in the returned list.
HTTP 400 because invoker asked for an url that is invalid
HTTP 404 because items to return are not found
Choose the one that best suits the way your API works.
I think it's safe to return an error (4xx + error info) in this situation because the offset can be exceeded by one of these assumptions:
A coding error
Invoker is not fetching data from begining (no fresh state)
Invoker ignored pagination data (present on each response)
You are not using total field in the response (which is optional because there are some situations where you can not count all items or simply it's very expensive counting them). In this case, if your last page has the same number of items (count) as the number of items asked for in the request (limit), there is no way to know that this is the last page, so you try another one. In that last request you will get a count=0 in the response and you can stop asking for pages. This case makes it fair to return a 200 code also because the programmer did exactly what you asked for in the API documentation.