How to use next_page_token in Get Multiple Leads by Filter Type?
If there is already a limit of 300 values per request, what is the place of the next_page_token input which is mentioned in the documentation?
http://developers.marketo.com/documentation/rest/get-multiple-leads-by-filter-type/
In addition, I have noticed that when I send around 500 lead s to filter I receive a next page token in the response. When should I expect to receive a next page token in the response?
Thanks in advance
The next page token is return when the set of leads filtered is greater than the batch size of the call(which defaults to 300). You can pass a subsequent call with the same filter and this next page token to return the additional records.
Related
I don't see nextSyncToken in the response. I followed the doc(https://developers.google.com/calendar/api/guides/sync) and paginated using nextPageToken but I couldn't see the nextSyncToken on the last page.
API Used: GET /calendars/primary/events?maxResults=10&singleEvents=true&pageToken=********
I don't know whether if I miss anything here. Could anyone help me with this?
I have seen from the response link on the other answer comment that you are using orderBy on the request.
This is why the nextSyncToken is not showing up.
As mentioned on the documentation on Events: list -> Parameters -> syncToken:
Token obtained from the nextSyncToken field returned on the last page of results from the previous list request. It makes the result of this list request contain only entries that have changed since then. All events deleted since the previous list request will always be in the result set and it is not allowed to set showDeleted to False.
There are several query parameters that cannot be specified together with nextSyncToken to ensure consistency of the client state.
These are:
iCalUID
orderBy
privateExtendedProperty
q
sharedExtendedProperty
timeMin
timeMax
updatedMin
If the syncToken expires, the server will respond with a 410 GONE response code and the client should clear its storage and perform a full synchronization without any syncToken.
Learn more about incremental synchronization.
Optional. The default is to return all entries.
You should remove the orderBy from the request to get the syncToken
Could you please provide the response from gcalendar API? It's hard to say more without detail information. I event don't know which language are you using.
Try to use a vendor library to sort that out:
a) https://packagist.org/packages/google/apiclient (for PHP)
b) https://www.npmjs.com/package/google-calendar (for JavaScript)
and/or
Try to use alternative endpoint: GET https://www.googleapis.com/calendar/v3/calendars/calendarId/events.
I'm trying to use delta query to get teams channel messages updates according this documentation: HERE
This is the request url:
https://graph.microsoft.com/beta/teams/<teamId>/channels/<channelId>/messages/delta
However, calling the returned nextLinks one after another never returns a deltaLink. There're too many pages of results and it causes my app to be throttled before ever getting a deltaLink from it.
In other delta query endpoints, $top is supported to limit the number of results returned. Usually I'm able to get a deltaLink after calling the nextLinks once or twice. But $top doesn't seem to have an effect in the channel messages endpoint.
So I tried appending another queryString ?odata.maxpagesize=10 to the request instead, and it seemed to work a week ago. I was able to get the deltaLink after 2 pages. But it looks like Microsoft might have changed the API and this workaround no longer works.
I also tried adding Prefer: odata.maxpagesize=10 in my request header according to this documentation: HERE
But the nextLink this generates is too long and it gives me this error instead:
HTTP Error 414. The request URL is too long.
Has anyone been able to use this delta for channel messages? Or have I done something wrong?
The clockify API is unclear (to me) about how to iterate through results.
For example, https://clockify.github.io/clockify_api_docs/#operation--workspaces--workspaceId--timeEntries--get says
Each request is limited to 10 time entries. To get the other 10 (and the next 10 and so on), you'll have to include the page parameter and increment it with each request (eg. https://api.clockify.me/api/workspaces/{workspaceId}/timeEntries/?page=1)
Data returned from this endpoint is merely an array of timeEntries (bonus for being simple!). Reading beyond the last page returns an empty array (status=200).
So, the question is: Does clockify intend that clients read until an empty array, or am I missing something?
This is the existing behaviour I am afraid.
Hopefully, there will be "CurrentPage", "PageLength", "TotalPages" or at least "TotalRecords" in the RESPONSE body someday.
EDIT:
According to the support response their developers are working on adding TotalRecords node to let us know how many items we can expect.
I am building an API where one can issue a POST to /users/1/suggestions/make in order to get a new suggestion. There are two cases:
the server can create a suggestion based on POSTed params, in which case a 200 status code is returned together with the created suggestion;
the server cannot create a suggestion based on POSTed params, in which case I am not sure what status code to return (200, since the request succeeded but nothing could be suggested, 404 because a suggestion could not be computed, or something else) and what content (nil, an empty response, something else).
If your POST is unsuccessful due to the parameters not passing validation, it is appropriate to return HTTP 400 Bad Request. The response body should consist of a list of the errors that caused the rejection.
This way it is clear to the API caller that no data has been modified.
Let's say you want to get list of users by calling GET to api/users, but currently the table was truncated so there are no users. What is the proper response for this scenario: 404 or 204?
I'd say, neither.
Why not 404 (Not Found) ?
The 404 status code should be reserved for situations, in which a resource is not found. In this case, your resource is a collection of users. This collection exists but it's currently empty. Personally, I'd be very confused as an author of a client for your application if I got a 200 one day and a 404 the next day just because someone happened to remove a couple of users. What am I supposed to do? Is my URL wrong? Did someone change the API and neglect to leave a redirection.
Why not 204 (No Content) ?
Here's an excerpt from the description of the 204 status code by w3c
The server has fulfilled the request but does not need to return an entity-body, and might want to return updated metainformation.
While this may seem reasonable in this case, I think it would also confuse clients. A 204 is supposed to indicate that some operation was executed successfully and no data needs to be returned. This is perfect as a response to a DELETE request or perhaps firing some script that does not need to return data. In case of api/users, you usually expect to receive a representation of your collection of users. Sending a response body one time and not sending it the other time is inconsistent and potentially misleading.
Why I'd use a 200 (OK)
For reasons mentioned above (consistency), I would return a representation of an empty collection. Let's assume you're using XML. A normal response body for a non-empty collection of users could look like this:
<users>
<user>
<id>1</id>
<name>Tom</name>
</user>
<user>
<id>2</id>
<name>IMB</name>
</user>
</users>
and if the list is empty, you could just respond with something like this (while still using a 200):
<users/>
Either way, a client receives a response body that follows a certain, well-known format. There's no unnecessary confusion and status code checking. Also, no status code definition is violated. Everybody's happy.
You can do the same with JSON or HTML or whatever format you're using.
I'd answer one of two codes depending on runtime situation:
404 (Not Found)
This answer is pretty correct if you have no table. Not just empty table but NO USER TABLE. It confirms exact idea - no resource. Further options are to provide more details WHY your table is absent, there is couple of more detailed codes but 404 is pretty good to refer to situation where you really have no table.
200 (OK)
All cases where you have table but it is empty or your request processor filtered out all results. This means 'your request is correct, everything is OK but you do not match any data just because either we have no data or we have no data which matches your request. This should be different from security denial answer. I also vote to return 200 in situation where you have some data and in general you are allowed to access table but have no access to all data which match your request (data was filtered out because of object level security but in general you are allowed to request).
If you are expecting list of user object, the best solution is returning an empty list ([]) with 200 OK than using a 404 or a 204 response.
definitely returns 200.
404 means resource not found. But the resource exists. And also, if the response has 404 status. How can you know users list empty or filled?
'/users' if is empty should return '200'.
'/users/1' if the id is not found. should return 404.
It must 200 OK with empty list.
Why: Empty table means the table exists but does not have any records.
404 Not Found means requested end point does not exist.