Issue property 404 response too general

I have an app that stores data in an issue property. When you read an issue property and get a 404 response there are two reasons for that. From the documentation:

Returned if the issue with given key or id does not exist, if the property with given key is not found, or if the user does not have permission to view the issue.

So there are two options:

  1. Issue with given id or key does not exist:

    {
        "errorMessages": [
            "Issue does not exist or you do not have permission to see it."
        ],
        "errors": {}
    }
    
  2. Property with given key does not exist:

    {
        "errorMessages": [
            "The property foobar does not exist."
        ],
        "errors": {}
    }
    

I would like to handle these two cases differently and thought I could just distinguish based on the error message. However, there is a problem here. I just noticed that the error message is localized, as in one of my customers has his Jira configured in Spanish and the message says: La propiedad foobar no existe.

This makes it practically impossible to distinguish the two cases unless you check for all possible languages that Jira offers.

Is this something Atlassian would consider to fix? I believe that there should be either a different HTTP error code for the two different cases or there should be an error code in the message that can be checked in code, independent of localization.

1 Like

Hi @tbinna,

as this is a feature request I would love it if you could file this as a ticket in our Developer Support Service Desk. This will help our team guide this request to the right internal people.

I certainly see merit in your proposal.

Cheers,
Peter

2 Likes

Sure, I will do that.

Thanks Peter!

2 Likes

Anyone interested in following this, this is the issue: https://jira.atlassian.com/browse/JRACLOUD-69258

So, I imagine that the decision to go with a 404 was consistent with why other API providers go with it – to keep bad actors from hunting for data by brute force or other methods. But the problem you describe is pretty darn interesting, because it appears that Atlassian has put in some extra info in errorMessages that could be useful for developers – but if your app relies on that, you’d need to bake in every localization string, which is silly.

Yep. I’ll vote for that. I wonder what the intent of the errors object is.

Hi, @tbinna,

I know it’s a workaround, but if your property name is distinctive enough, you can search for its occurrence in the error message and if:

  • the message contains the property name -> the property was not found
  • it doesn’t -> the issue was not found

This relies on the fact that in all languages the message should contain the property name if the property is not found.

On a side note, if it’s any consolation, we’ve recently realized that localizing messages returned by REST APIs doesn’t serve any real purpose (on the contrary, can only do harm, as demonstrated by this case) and we don’t do that any more for new endpoints.

Cheers,
Krzysztof

2 Likes

Hi @kkercz,

Thanks for the details the suggested solution. You are right, in my case, this should be working fine :+1:

I am ok with this for now, yet I think it would be good if developers could rely on a more stable indicator other than these messages. Maybe something in the errors object, like @nmansilla mentioned?