nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How do I make an API call with cURL with a JQL that has spaces in it, and has expand=changelog added

chrisyeem

Hello, this feels like a bug but I'm not sure. I have a Jira call that I am trying to make. It's to get the list of bugs in a project and their changelog history so I can get the creation date and timstamp that a label gets set. I am using the following cURL command

/usr/bin/curl \
-s -u user@company.com:APIKEY -X GET \
-H "Content-Type: application/json" \
https://company.atlassian.net/rest/api/2/search?expand=changelog&jql=project=KEY%20and%20issueType=BUG

This is not pulling up all bugs in the project KEY, it's pulling up all jiras period, in the jira instance. Replacing %20 with + doesn't change anything, it still results in the jql being ignored.

Now if I swap expand=changelog and jql=project=KEY%20and%20issueType=BUG so that it's

/usr/bin/curl \
-s -u user@company.com:APIKEY -X GET \
-H "Content-Type: application/json" \
https://company.atlassian.net/rest/api/2/search?jql=project=KEY%20and%20issueType=BUG&expand=changelog

it will pull down all bugs in the project KEY, but it does not expand the changelog, resulting in it not including the bug histories of the bug that I am trying to get, which is what I want

Now if I paste either of the URIs in the browser, they work just fine, so it's something about how cURL is handling it, so I'm not sure what I'm missing here.

Any suggestions? Any assistance would be appreciated.

Accepted answers

chrisyeem

I figured it out. I used the --get and the --data parameters to move the GET params out of the URL.

from cURL's manpage

-G, --get
When used, this option will make all data specified with -d, --data, --data-binary or --data-urlen‐
code to be used in an HTTP GET request instead of the POST request that otherwise would be used. The
data will be appended to the URL with a '?' separator.

If used in combination with -I, --head, the POST data will instead be appended to the URL with a HEAD
request.

If this option is used several times, only the first one is used. This is because undoing a GET
doesn't make sense, but you should then instead enforce the alternative method you prefer.

So changed my cURL call to

/usr/bin/curl \
-s -u user@company.com:APIKEY -X GET --get \
-H "Content-Type: application/json" \
--data 'jql=project=KEY+and+issueType=BUG&expand=changelog' \
'https://bymason.atlassian.net/rest/api/2/search'

And that seems to be working.

It not working in the URI itself has got to be a bug in cURL

All comments

Thomas Deiler_db00h3

Dear @chrisyeem ,

As far as I can see, everything is correct. So the source of your issue could be curl, itself. It could be linked to the false library. Or the charset of your shell is suppressing the characters.

You can try to rebuild curl on your own from source and install at /usr/local/bin in parallel.

Have you tried another Linux distribution?

Just to be sure: /rest/api/2 is the path to server, not cloud. That's not the cause, or?

So long

Thomas

chrisyeem

I figured it out. I used the --get and the --data parameters to move the GET params out of the URL.

from cURL's manpage

-G, --get
When used, this option will make all data specified with -d, --data, --data-binary or --data-urlen‐
code to be used in an HTTP GET request instead of the POST request that otherwise would be used. The
data will be appended to the URL with a '?' separator.

If used in combination with -I, --head, the POST data will instead be appended to the URL with a HEAD
request.

If this option is used several times, only the first one is used. This is because undoing a GET
doesn't make sense, but you should then instead enforce the alternative method you prefer.

So changed my cURL call to

/usr/bin/curl \
-s -u user@company.com:APIKEY -X GET --get \
-H "Content-Type: application/json" \
--data 'jql=project=KEY+and+issueType=BUG&expand=changelog' \
'https://bymason.atlassian.net/rest/api/2/search'

And that seems to be working.

It not working in the URI itself has got to be a bug in cURL

chrisyeem

For the /rest/api/2 question, I just followed what I saw in https://developer.atlassian.com/server/jira/platform/jira-rest-api-examples/ which I only have just realized is for server, not cloud, but that part was always working, so I don't know why that is. I am on cloud. What should the path be for cloud?

chrisyeem

I figured it out. I used the --get and --data arguments to move the GET params into their arguments and out of the URI. From the cURL manpage

-G, --get
When used, this option will make all data specified with -d, --data, --data-binary or --data-urlen‐
code to be used in an HTTP GET request instead of the POST request that otherwise would be used. The
data will be appended to the URL with a '?' separator.

If used in combination with -I, --head, the POST data will instead be appended to the URL with a HEAD
request.

If this option is used several times, only the first one is used. This is because undoing a GET
doesn't make sense, but you should then instead enforce the alternative method you prefer.

So my new curl call to the API is

/usr/bin/curl -s -u user@company.com:APIKEY -X GET --get \
-H "Content-Type: application/json" \
--data 'jql=project=KEY+and+issueType=BUG&expand=changelog' \
'https://bymason.atlassian.net/rest/api/2/search'

Not sure why the params don't work in the argument directly. Seems like a bug. But this works

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-software

jira-software-cloud

rest

rest-api