I'm calling this API method:
https://learn.microsoft.com/en-us/rest/api/azure/devops/build/builds/list?view=azure-devops-rest-6.0#response
My API url (with placeholder names):
https://dev.azure.com/MyOrgName/MyProjName/_apis/build/builds?api-version=6.1-preview.6
The results are mostly appropriate, except I get a filtered list of builds, and I can't seem to get all the builds I want. In particular, builds from several pipelines are simply missing, and I can't find any way to include them. There's no discernable reason why some builds are included, and some are not.
The filter options describe ways I could reduce it more, but that's not my goal. I want to retrieve builds which I am otherwise not getting. And I don't know what option that I don't know about which will get me the results I care about.
As you have already noticed, there is a maximum number of the objects that can be listed on the response body of each API call. Normally, if the objects you want to list are too many, they will be returned in multiple pages.
In the response body of each call, generally there is a parameter 'continuationToken' (see here). You can access the next response page via calling the API with this parameter.
GET https://dev.azure.com/{organization}/{project}/_apis/build/builds?continuationToken={continuationToken}&api-version=6.1-preview.6
For example:
the first call returns the list in the first page;
then run the second call with the parameter 'continuationToken' returned in the response of the first call to get the second page;
then get the third page using the 'continuationToken' returned in the second response;
. . .
until the last page.
If you want to traverse all the pages, you may need to call the API in a loop.
Related
If I navigate to /rest/api/2/issue/createmeta/PROJ/issuetype/N (in this case, I'm getting Task), the list of fields returned is incomplete. There are a number of customfields that are in use (I can see them both in the tickets themselves, and also in /plugins/servlet/project-config/PROJ/fields ) that are in the createmeta data.
I'm really trying to do this in python jira, where I'm using "expand='projects.issuetypes.fields'" in the createmeta() call, but I figured I'd double-check the results in the rest API directly, and I'm getting the same results there, too.
This is happening in jira 8.20.7.
Essentially, what I'm trying to do, is to programatically get a name/id mapping of all fields in the ticket type. I'm having far more difficulty doing that than I thought there would be. I would do it based on /rest/api/2/field but the jira admins have allowed some duplicated names...
EDIT: I realized that it might be worth noting that some of the fields I'm looking for are coming from a ServiceDesk form, although, as far as I can tell, there's no way to determine that, since one of the missing fields contains the name of the form.
Why are you using createmeta endpoint?
Instead of that, in order to get all of the customfields and their values; just note their id and get the values from /rest/api/2/issue/{issueKey} endpoint.
When you send a GET request to /rest/api/2/issue/{issueKey} endpoint, you will get a JSON object which contains "fields" object in it.
And using the "fields" you can determine all of the values that include system fields (description, assignee, etc.) and custom fields (like customfield_<customfieldid>).
And for a general approach, you may want to look at the field types in that response.
I'm trying to fetch details from VSTS using VSTS query API. So to get all Portfolio Epics I created a custom query and used its ID to get that in JSON format. the query looks like this
https://dev.azure.com/{organization}/{project}/{team}/_apis/wit/wiql/{id}?api-version=5.0-preview.2
But the issue is its not giving me many details about each of the work items in JSON. It only lists the ID and URL. Like this
WorkItems:[
{ID:234,URL:"workitemurl"},
{ID:235,URL:"workitemurl"},
{ID:236,URL:"workitemurl"},
...
]
So if I need more details about an item I need to execute those individual URl for each PE and thus I can get its details. instead of I am just checking is there is any way of getting an ID (keyedinID of each work item along with the ID and URL) like this. Please note KID is a field if we execute the URL separately. So to avoid that extra process, I would like to get that along with the WorkItems.
WorkItems:[
{ID:234,URL:"workitemurl",KID:002},
{ID:235,URL:"workitemurl",KID:023},
{ID:236,URL:"workitemurl",KID:033},
...
]
So how can we make this possible?
The Web UI uses a different API to get query results (/_api/_wit/_query), which allows query+data in a single pass. This is an old __v5 type call, which means it's considered internal.
The proper way to do this now is to first do the query as you're doing it right now and then call /_api/wit/workitems?ids=1,2,3,4 using the IDs from the references you got from the first call. That will also allow you to load the details dynamically and in small batches which will result in a more responsive UI.
See:
https://learn.microsoft.com/en-us/rest/api/azure/devops/wit/work%20items/list?view=azure-devops-rest-4.1
I'm using Microsoft Graph to get a list of messages for a user.
I'm using the following URL
https://graph.microsoft.com/v1.0/me/mailFolders/inbox/messages
One important thing that is returned by this is the meetingMessageType when the message revolves around a meeting request.
I would also like to get the uniqueBody of the message. However, that's not provided by default. One needs to specifically ask for that field. I can do that by adding ?$select=uniqueBody to the URL.
However, that now means that I need to add the rest of the fields I want to the $select query parameter. That's not a big deal until I run into meetingMessageType. Microsoft Graph returns:
Could not find a property named 'meetingMessageType' on type 'Microsoft.OutlookServices.Message'.
What can I do to ensure I get both uniqueBody and meetingMessageType?
Try this:
$select=uniqueBody, microsoft.graph.eventMessage/meetingMessageType
Yogesh's answer is close but will result in a Only one level select is supported error.
As long as you don't care about the value of meetingMessageType, you can use this select:
$select=microsoft.graph.eventMessage, uniqueBody
You'll note that the results no longer include meetingMessageType as a property. The list however is limited to only those messages that are eventMessage, effectively giving you a result set filtered to only show meeting requests.
I want places information from google places so I used "nearbysearch" API.
But it is only returning 1st 20 place information. So I used next_page_token to get places information which is on 2nd page but still it is returning information of places which are already there on 1st page.
response=HTTParty.get("https://maps.googleapis.com/maps/api/place/nearbysearch/json?location="+params[:place][:latitude]+","+params[:place][:longitude]+"&radius="+params[:place][:radius]+"&types="+params[:place][:type]+"&key=AIzaSyAD6Vgkz7vo-nZLZp-xeNoPchOr7RepWEU")
receipt=JSON.parse(response.body)
#next_page_token=receipt['next_page_token']
response2=HTTParty.get("https://maps.googleapis.com/maps/api/place/nearbysearch/json?location="+params[:place][:latitude]+","+params[:place][:longitude]+"&radius="+params[:place][:radius]+"&pagetoken=#{#next_page_token}&types="+params[:place][:type]+"&key=AIzaSyAD6Vgkz7vo-nZLZp-xeNoPchOr7RepWEU")
This is happening because both of these is true:
The &pagetoken= parameter of your request doesn't contain a valid page token (perhaps there is no second page of results, so it's just an empty string?). This is your main problem. Also,
Your second request repeats all the parameters, even though you don't need to with a page token. The original request + an invalid pagetoken= is treated like the original request, as you've noticed :)
So you should:
manually verify that #next_page_token holds what you expect and fix what that reveals. E.g. at the least you should add logic to deal with the case where the response doesn't have a next_page_token, and
change the second request to omit all parameters other than key and pagetoken, so that the unnecessary parameters don't mask your main bug.
My setup: Rails 2.3.10, Ruby 1.8.7
I need to implement an API that is essentially a GET but depending on a date, could involve DELETE and POST actions as well. Let me explain, for a particular day, the API needs to add 10 items to one table randomly selected from another table but this is only done once a day. If the items added are from the previous day, then the API needs to delete those items and randomly add 10 new ones. If multiple calls are made to the API in the same day, then it's just a GET after the initial creation. Hope this makes some sense.
How would I implement this as a RESTful API if at all possible.
How about?
GET /Items
If the next day has arrived, then generate 10 new items before returning them. If the next day has not arrived, then return the same 10 items you previously returned. There is no reason the server cannot update the items based on a GET. The client is not requesting an update so the request is still considered safe.
Not sure if I'm understanding you correctly, but just by looking at this, all I can think is the following: What a horrible thing, to perform an add which depending on what it's added, performs a delete. No disrespect, but seriously. Or maybe it is the way you are describing it.
Whatever the case, if you want to have a RESTful API, then you have to treat GET and PUT distinctively.
I don't think you have a clear use-case picture of how your API (or your system for that matter is to be done.) My suggestion would be to re-model this as follows:
Define a URI for your resource, say /random-items
a GET /random-items gets you between 0 and 10 items currently in the system.
a PUT/random-items with an empty body does the following:
delete any random items added on or before yesterday
add as many random items as necessary to complete 10
an invocation to DELETE /random-items) should return a 405 Method Not Allowed http error code.
an invocation to POST/random-items` should add no more than 10 items, deleting as needed.
/random-items/x is a valid URI so long as x is one of the items currently under /random-items.
A GET to it should return a representation for it or a 404 if it does not exist
A DELETE to it deletes it from under /random-items or 404 if it does not exist
A PUT to it should change its value if it makes sense (or return a 405)
A POST to it should return a 405 always
That should give you a skeleton sorta RESTful API.
However, if you insist, or need to overload GET so that it performs the additions and deletions behinds the scene, then you are making it non-RESTful.
That in itself is not a bad thing if you legitimately have a need for it (as no architectural paradigm is universally applicable.) But you need to understand what RESTful mean and when/why/how to break it.