Loading Profile...
API inconsistency
GET POST and PUT all offer different issue elements
GET: misses: fixfor, affected, resolution, resolvedBy, resolvedOn, closedOn
PUT misses: createdBy
POST misses: resolution, resolvedBy, resolvedOn
I get that the GET operation might already be filtered on `closed == false` but stricly speaking if i do a REST operation on /api/projects/{id}/issues/ the only filter that from a REST perspective was specified is the projectid.
In any case the exposed entity that the REST operations are performed on should not be different depending on the HTTP method used.
GET: misses: fixfor, affected, resolution, resolvedBy, resolvedOn, closedOn
PUT misses: createdBy
POST misses: resolution, resolvedBy, resolvedOn
I get that the GET operation might already be filtered on `closed == false` but stricly speaking if i do a REST operation on /api/projects/{id}/issues/ the only filter that from a REST perspective was specified is the projectid.
In any case the exposed entity that the REST operations are performed on should not be different depending on the HTTP method used.
I’m riguriously adding null checks to my mapping classes!
1
person has this question
I have this question, too!
Tell me when someone answers.
The more people who ask this question, the more it gets noticed.
The more people who ask this question, the more it gets noticed.
Create a customer community for your own organization
Plans starting at $19/month
-
Inappropriate?I agree this is inconsistent. I presume most of this was added in to make the API operations "convenient" when making raw calls but didn't take into account cases where the entire object might be mapped!
We will take a look at this one.1 Comment
Add a comment
This answers the question
-
Also, closed == false is the default filter for everything, i.e. if you want closed issues, you need to explicitly filter. I presume this carries on to the API! -
Inappropriate?Yeah makes sense why it happens doesn't make too much sense from a pure REST sense though :) Another one GET returns "<hidefromclients>bool" wich is undocumented.</hidefromclients>1 Comment Add a comment
This answers the question
-
I agree. We will have a look at this issue definitely and I've asked for the hideFromclients to be documented.
-
Inappropriate?Having worked just a tad bit longer with the Fixx API i think the reason why some of the examples seem to miss certain elements is that they were simply 'null' when they were rendered :) I think for sanity sake the examples should show the entire object and mention that elements will disappear if they are 'null'.
I’m happy to see data appear in unexpected places.
1 Comment Add a comment
This answers the question
-
Ah. I didn't realise this might be the issue. I have updated the issue with this :)
-
Inappropriate?Also there is no automatic filter on closed issues. I.e /projects/{project_id}/issues is only filtered by project in strict accordance of REST :)
I’m sorry for jumping the gun!
1 Comment Add a comment
This answers the question
-
The new filtering system in 1.9 should address this.
EMPLOYEE
