Since version 2018.3, YouTrack has published a new API for administrating the system. One example of a new endpoint is /api/admin/users/ which is supposed to return the collection of users in the YouTrack instance, with a wide variety of fields being available compared to the old, deprecated, API.
However, when using it, I've found that it returns only a subset of all users in the instance; in my case, it produces only 42 out of 106 users.
As a workaround, I've used the deprecated API endpoint, /rest/admin/user/ to get all users, and called the new endpoint for each of the 106 results to get the newly available detailed information, but this is rather wasteful in the number of calls required, adds a dependency on a deprecated API, is altogether pretty wonky, and doesn't appear to be the intended workflow.
So the question becomes: How does one use the new API to get all users?
There is a default limit for a result array which is 42.
You can override it by sending /api/admin/users/?$top=<YOUR_LIMIT> , you can also send -1 to get the whole set of users (may cause performance issues).
Additionally, you can use a combination of $top and $skip get parameters to iterate through your users.
Related
I have been tasked to build a custom interface for Youtrack and am using the new YouTrack APIs - docs here https://www.jetbrains.com/help/youtrack/standalone/youtrack-rest-api-reference.html. I am querying for a full list of issues which returns 1.17 MB of data. The problem is this takes a while and I only need issues with specific fields ie Priority=1 and Type=Task.
Is there a way to filter with the new APIs so I don't return 1.17 MB of data?
I see that the deprecated APIs (https://www.jetbrains.com/help/youtrack/standalone/deprecated-rest-api-reference.html) have a filter field, but I cannot find one in the new API documentation. I have tried including filter=Priority and filter=Priority(name=1) to see if there are some undocumented filtering methods, but no luck thus far.
Example call: GET https://example.myjetbrains.com/youtrack/api/issues?fields=id,description,fields(id,name,value(id,name)) which returns 1.17 MB of data.
Ideally, I would like to do GET https://example.myjetbrains.com/youtrack/api/issues?filter=Priority(name=1),fields=... or something similar.
It's possible to apply a filter to the returned issues list the same way as for the old API. Have a look at https://www.jetbrains.com/help/youtrack/standalone/resource-api-issues.html#get_all-Issue-method. The only difference in this regard is that the field field is called 'query', not 'filter'.
Is there anyway to find out how many webapi calls that are used against quota when doing rest API call (or soap api call) reading leads from a list? Please note that this is purely read-only, where we are getting data from a static list of leads, which are added using a smart campaign.
We are bringing in 40 attributes from the Marketo lead record total 1600 chars. Depending on need, we might need to stage anywhere from 200K to 1 million records into a static list. We are successfully extracting all that data, but we would like to find out how many API calls are being utilized.
Each authenticated request to an endpoint counts as a call. You can also the usage API to see your daily usage: http://developers.marketo.com/documentation/rest/get-daily-usage/
There appear to be two lines of APIs for adding, authenticating and aggregating sites. Depending upon which version of the Documentation/SDK set your rep started you off on, or where in the SDK Guide you started implementing from determines where you start.
Path #1 starts at
ContentServiceTraversal which allows for the retrieval of all ContentServiceInfo (by container type (such as BANK)
ItemManagementService is used to add these items
Refresh is done through RefreshService (most API not containing the word Site)
Path #2 starts at
SiteTranversalService which allows for the retrieval of all SiteInfo (no apparent support for Container Type filter)
SiteAccountManagementService is used to add these items
Refresh is done through Refreshservice (all API containing the word Site).
From the best that I can tell the aforementioned API have a lot of functionality duplication. I have noticed certain API that exist on one branch and not the other but usually they are minor changes (e.g. things you are able to filter by).
I started off with ContentServiceInfo because the documentation and samples that our rep initially gave us started there. Additionally this API started off by providing greater granularity (e.g. simply being able to filter by Container type since we were pretty much only interested in Banks and Processor sites (which I do not believe you guys support)).
My questions are:
Do the two branches of API do the exact same thing?
Do they mostly behave the same way?
Do they back-end to the exact same
System
Data store
Scraper?
Is one line of API supposed to be deprecated sooner in the future than another?
Does one line of API have more future in terms of actually adding new or augmenting existing functionality?
Site-level addition has been introduced through Yodlee APIs to overcome the fact that though a user had bank,creditcard,loan,rewards account at the same end site, user had to provide credentials for each of these containers. Site level addition APIs try to add all these containers with only 1 set of credentials. That's the only difference between container based addition and site based addition.
As to answer your questions:
Do the two branches of API do the exact same thing?
Do they mostly behave the same way?
If you mean the aggregation functionality, Yes.Except for the fact that Site level adds/refreshes all the container(bank,creditcard,loan,rewards) and Container level can add/refresh only one container per API call, all the other behavior will remain the same.
Do they back-end to the exact same
System
Data store
Scraper?
If you are referring to the Yodlee data gathering components, Yes.
Is one line of API supposed to be deprecated sooner in the future than another?
No.Both these sets of APIs cater to different needs. If you are a company who solely rely on Creditcard data, using site level addition will be overkill as it will take longer time for the aggregation and it makes more sense to use container based addition. There is also the factor of backward compatibility, which rules out deprecation of APIs.
I'm trying to pull from the API of story counts for the latest release, broken down by schedule state. There's a report that does that currently, but I don't see any exposed method in the API. Does anyone know if that's possible to obtain?
You should be able to do a query for each schedule state, and grab TotalResultCount from the body of the response. For example:
https://rally1.rallydev.com/slm/webservice/1.31/hierarchicalrequirement.js?query=(ScheduleState = "Defined")
https://rally1.rallydev.com/slm/webservice/1.31/hierarchicalrequirement.js?query=(ScheduleState = "In-Progress")
and so on. Since there are only four "built-in" schedule states, plus an optional one before Defined and an optional one after Accepted, it's at most 6 requests.
You can further filter down Alan's examples above with some release information as well by changing the query parameter:
query=((ScheduleState = Defined) AND (Release.Name = "My Release"))
Are you writing an app using the App SDK or using one of our other REST toolkits (ruby, .net, python)? You may be able to find some better code examples here:
http://developer.rallydev.com
You might also try the Batch Query approach that allows you to just return the size of the query instead of counting the results. See the
"Getting the Size of a Collection" example of the api doc:
https://rally1.rallydev.com/slm/doc/webservice/batch.jsp#example8
I wrote a little Script using Python and Tweepy to save the tweets for a list of users and also to get some basic properties for those accounts.
Somehow the number of tweets stated in the user profile under statuses_count
(for an example of the json description of an account:
https://api.twitter.com/1/users/show.json?screen_name=TwitterAPI&include_entities=true )
does not match the number of tweets i get when iterating through the tweets of the same users profile.
I am aware of the fact, that twitter limits the number of tweets per user available through the API to 3200 and even does not guarantee this number, but this behavior does even occur with users who have well less than 3200 tweets
My question is, whether this difference is common and why this happens?
Is this just an issue of the twitter API, is it caused by deleted tweets (maybe they still count for statuses_count but can not be fetched anymore?), ...?
Thanks!
Thomas
I haven't messed with the Twitter API in several months, but I remember back when I was working with it I found inconsistencies due to retweets not showing up when iterating tweets, but getting counted in the number of Tweets. This seems to corroborate that, but its several months old and things may have changed since then.
Make sure include_rts is set to true, t, or 1 (in addition to specifying the same for include_entities, which you have done). When these aren't included by default (e.g. user lists) then you can get fewer tweets than what you specified with count.
The Twitter API documentation isn't clear on what the defaults are so it's safer to explicitly specify these optional parameters. And since you're specifically working with the user timeline you might also want exclude_replies turned off.