I'm using the JIRA REST API and I would like to query for all issues in "Resolved" status. The status field looks like this:
"status": {
"self": "https:\/\/jira.atlas.xx.com\/rest\/api\/2\/status\/5",
"description": "A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed.",
"iconUrl": "https:\/\/jira.atlas.xx.com\/images\/icons\/statuses\/resolved.png",
"name": "Resolved",
"id": "5",
"statusCategory": {
"self": "https:\/\/jira.atlas.xx.com\/rest\/api\/2\/statuscategory\/3",
"id": 3,
"key": "done",
"colorName": "green",
"name": "Complete"
}
}
Currently the only way to know to do this is to query for status=5. It would be nice to make the query more intuitive and look for all issues using the string "Resolved" status. Here is the query I'm using:
https://jira.atlas.xx.com/rest/api/2/search?jql=project=MYPROJECT and status=5 and fixVersion=15824&fields=id,key,description,status
Is it possible to query on status name?
Yes, you can query on status name as well.
I think you should use the official Jira documentation, especially this when using advanced searching options like JQL queries.
This documentation describes every part of your possible JQL queries. If you look at the Fields reference section, there you will find the fields as well as the possible attributes on which you can search. For example, in case of Status field:
You can search by Status name or Status ID (i.e. the number that JIRA automatically allocates to a Status).
According to this, your query can be modified easily
https://jira.atlas.xx.com/rest/api/2/search?jql=project=MYPROJECT and status=Resolved and fixVersion=15824&fields=id,key,description,status
If you can type the JQL in the browser, you can use it as a string for the REST API search resource. So you can indeed search by status name, suitable quoted
Related
In my case, each user has a profile with lots of attributes, e.g. gender, age, name. What's the best practice to design the RESTful API to get those attributes? The followings are possible solutions:
Get all attributes in a single call
Get all attributes:
Request: GET http://api.domain.com/users/id/profile
Response: {"name" : "Jim", "gender" : "male", "age" : 12}
Get attribute one-by-one
Get attributes list:
Request: GET http://api.domain.com/users/id/profile
Response: { "attributes" : ["name", "gender", "age"] }
Get a specified attribute:
Request: GET http://api.domain.com/users/id/profile/name
Response: {"name" : "Jim"}
With the first solution, the client gets all attributes in a single call. However, the problem is that there's too many attributes, and we'll add more attributes to the profile. I'm wondering which one is better?
If you have lots and lots of attributes, another approach would be to group them.
In REST, everything needs to be a resource (for example, but not limited to, something identifiable by an URL).
So you could have
GET http://api.domain.com/users/id/profile
and you get
{ "categories" : ["names", "address", "interests", "jobhistory", "publications", "blogs", "skills"] }
and then you query further. That does imply multiple trips but you would not have to query the many attributes one by one, ending up with 50 queries out of 75 attributes, for example, but might need 3 queries to get the 50 attributes you want.
Definitely the first option seems much better primarily because of saving multiple calls - mind you clients as well, it will be much easier for them to fetch what they need in a single call instead of calling - more or less - the same resources multiple times.
It seems that what are you looking for is called resource expansion - you can read about it e.g. here.
In short it assumes that the response you send is configurable with query params. If no params are included some basic subset of attributes is returned. If params to be expanded are sent - the basic subset is returned along with other attributes listed in query param. You can also mix two approaches. Some of parameters might be expanded via query params other may be called as subresources - it depends arbitrarily on the size of a resource.
I would recommend to divide user profile attributes into logical categories and make these categories available to your clients through query parameters like ...
names (array of names (aliases)) : first, last, middle, prefix
addresses (array of addresses) : street, apt, city, state, country, county
jobs (array of jobs) : company, designation, start_date, end_date, city, state, country
Provide an API that returns the up-to-date list of categories available on user profile as documentation can get outdated.
GET http://api.domain.com/users/profiles/categories
Response:
{
"categories": ["names", "address", "interests", "jobs" ],
"links": [
{
"rel": "users.profiles.categories",
"href": "http://api.domain.com/users/profiles/categories"
}, {
"rel": "users.profiles.category.names",
"href": "http://api.domain.com/users/profiles?categories=names"
}, {
"rel": "users.profiles.category.addresses",
"href": "http://api.domain.com/users/profiles?categories=addresses"
}, {
"rel": "users.profiles.category.interests",
"href": "http://api.domain.com/users/profiles?categories=interests"
}, {
"rel": "users.profiles.category.jobs",
"href": "http://api.domain.com/users/profiles?categories=jobs"
}, {
"rel": "users.profiles.category.all",
"href": "http://api.domain.com/users/profiles?categories=all"
}
]
}
With the above HATEOAS and depending on the categories mentioned in query parameter, your service can query those entities from database and form the response and return back to your client.
GET http://api.domain.com/users/id/profile?categories=names,address,interests,jobs
NOTE: if comma(,) cannot be not directly used in URL then you can use %2C (url-encoded value of ,).
Additionally, your actual GET API can also return HATEOAS to sub categories if the user doesn't use the categories API to get all sub categories.
This is just one of the way where you can using additional informative end point provide available/supported categories (query parameters) and HATEOAS will help your client to navigate thru those available sub-categories.
We have several API endpoints like:
/api/cities/ => Fetches all cities in our database. Its an oversimplified example, actually we have around 1k cities.
{
"name": "Chicago",
"name": "Los Angeles",
"name": "New York",
"name": "Phoenix"
}
Currently these API returns city list in alphabetic order.
We have new requirement where we need to fetch popular cities at the top, this followed by list in alphabetic order.
JSON Output would look like:
{
"popular"
{
"name": "New York",
"name": "Los Angeles"
},
"all"
{
"name": "Chicago",
"name": "Los Angeles",
"name": "New York",
"name": "Phoenix"
}
}
How should current APIs be modified to fulfil this:
Should we create new API like /api/popularcities/ which would fetch list of popular cities? This way client would call /api/popularcities/ first and then /api/cities/ API.
Should we add query string parameter in existing API /api/cities/?fetch=popularall to fetch both popular and all cities.
Or any other thing, this doesn't look like filter attribute as this is actually adding result at the top and not filtering it out.
We do need to repeat popular cities in all city list as this would be binded directly to UI dropdown and requirement is to keep alphabetic ordering intact.
Suggestions?
popular cities are a way of sorting for the same entities.
It shouldn't be a new resource, but a way of querying the same resource sorted differently to get the needed entries.
I would use a query for that: ?sort=popular.
you can use both endpoint, a endpoint like as shortcut of api fetch all with order by popular.
/cities?sort=popular
/popular_cities
So... I am aware that this question could be dangerously close to being opinion based . I'm hoping is not, and that the REST standard is clear about what I'm going to ask but if it's not, I'll close it.
I have a website (in Django, with the data being stored in Postgres) with Product(-s) and Category(-ies) Each category can contain several product(-s).
So, the question is: What would be the "right" endpoint (if there's any) to GET all the categories with all the products in each?
I believe it would be clear getting all the products of a specific category. For instance, if the category ID was 24, in order to get all its products, I would write:
http://myserver.com/api/categories/24/products
But how about ALL the categories with ALL the products in each?
Would it be http://myserver.com/api/categories/products?
Would it be http://myserver.com/api/categories/all/products?
Would it be better using some kind of parameter, such as http://myserver.com/api/categories?mode=all_products ?
The idea would be having a response like this (JSON format)
{
"25": [{
"id": 1,
"name": "Product 1 in category 25",
"price": 100
}, {
"id": 2,
"name": "Product 2 in category 25",
"price": 200
}],
"26": [{
"id": 3,
"name": "Product 1 in category 26",
"price": 300
}, {
"id": 4,
"name": "Product 2 in category 26",
"price": 400
}]
}
Thank you in advance.
As far as REST is concerned if you are uniquely representing the resource in the url so that it is cacheable (and abiding with HATEOAS but let's skip that part), it doesn't really matter how you structure your urls. With that said in my opinion, since you want to get all the products, your url should be something like
GET /products # to return all products with their associated categories
GET /category/24/products # to return all products belonging to a particular category
Note:- Although url structure is not exactly a part of REST, but designing url in terms of an entity/resource and an identifier does makes it easier to create RESTful APIs. Well structured urls also makes them easier to be consumed by clients.
I'm trying to search and retrieve news articles on Alchemy Data News. I can get results using entities:
https://access.alchemyapi.com/calls/data/GetNews?apikey=[redacted]&outputMode=json&start=now-60d&end=now-0d&maxResults=10&return=enriched.url.title,enriched.url.url,enriched.url.entities,enriched.url.concepts&q.enriched.url.entities.entity=|text=Neil%20Tyson,type=Person|
and I can get results using keywords:
https://access.alchemyapi.com/calls/data/GetNews?apikey=[redacted]&outputMode=json&start=now-60d&end=now-0d&maxResults=10&return=enriched.url.title,enriched.url.url,enriched.url.entities,enriched.url.concepts&q.enriched.url.enrichedTitle.keywords.keyword.text=solar%20System
but if I combine the two I just get results that say "OK":
https://access.alchemyapi.com/calls/data/GetNews?apikey=[redacted]&outputMode=json&start=now-60d&end=now-0d&maxResults=10&return=enriched.url.title,enriched.url.url,enriched.url.entities,enriched.url.concepts&q.enriched.url.enrichedTitle.keywords.keyword.text=solar%20System&q.enriched.url.entities.entity=|text=Neil%20Tyson,type=Person|
{
"status": "OK",
"usage": "By accessing AlchemyAPI or using information generated by AlchemyAPI, you are agreeing to be bound by the AlchemyAPI Terms of Use: http://www.alchemyapi.com/company/terms.html",
"totalTransactions": "4320",
"result": {
"status": "OK"
}
with no docs. Is this supposed to work, or am I barking up the wrong tree?
The problem is you've created a query with 0 results. If you remove the &return portion of the query the response will include only a count. You can also add &timeSlice to see results by time bucket (more on counts and time slice here). Running your combined query with a monthly time slice (&timeSlice=1M) returns:
"status": "OK",
"totalTransactions": "4322",
"result": {
"count": 0,
"slices": [
0,
0
],
"status": "OK"
}
An example of the combining entity and and concept with many recent/topical response (at least during Feb 2016) is replaceing Solar System with B.o.B:
https://access.alchemyapi.com/calls/data/GetNews?outputMode=json&start=now-60d&end=now-0d&maxResults=10&return=enriched.url.title&enriched.url.url&enriched.url.entities&enriched.url.concepts&q.enriched.url.entities.entity.text=Neil+Tyson&type=Person&q.enriched.url.enrichedTitle.keywords.keyword.text=B.o.B&apikey=<YOUR API KEY>
and that's where the focus of this service is, querying and helping identify trends in recent news.
I'm working with Fi-Ware and I would like to include existing information from smartcities on my project. Clicking on the link below I could find information about how is the ID pattern and type of different device (for example OUTSMART.NODE.).
https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/Publish/Subscribe_Broker_-_Orion_Context_Broker_-_User_and_Programmers_Guide#Sample_code
However, I don't know the after that pattern
I've tried random numbers (OUTSMART.NODE.1 or OUTSMART.NODE.0001).
Is there some kind of list or somewhere to find that information??
Thank you!
In order to know the particular entity IDs for a given type, you can use a "discovery" query on the type associated to the sensor with the .* global pattern. E.g., in order to get the IDs associated to type "santander:traffic" you could use:
{
"entities": [
{
"type": "santander:traffic",
"isPattern": "true",
"id": ".*"
}
],
"attributes" : [
"TimeInstant"
]
}
Using "TimeInstant" in the "attributes" field is not strictly needed. You can leave "attribute" empty, in order to get all the attributes from each sensor. However, if you are insterested only in the IDs, "TimeInstant" would suffice and you will save length in the JSON response (the respone of the above query is around 17KB, while if you use an empty "attributes" field, the response will be around 48KB).
EDIT: since the update to Orion 0.14.0 in orion.lab.fi-ware.org on July 2nd, 2014 the NGSI API implements pagiation. The default limit is 20 entities so if you want to get all them, you will need to implement pagination in your cliente, using limit and details URI parameters. Have a look to the pagination section in the user manual for details.