Could not reproduce. Here is what I get when I post a request for a parameterized build (my HEAD is 5b4b66d8bcc4c3effae9329236edbfac2bccdd84 in branch 'master'):

$ curl -i -X POST http://localhost:8080/job/bnt_02/buildWithParameters?profile=foo
HTTP/1.1 201 Created
X-Content-Type-Options: nosniff
Location: http://localhost:8080/queue/item/55/
Content-Length: 0
Server: Jetty(winstone-2.8)

$

I am having the same problem. It appears to be happening when you POST to a build containing multipart form data. For example:

curl -i curl.log -X POST http://localhost:8080/jenkins/job/TestProject1/build?  --user user:password   --form file0=@Documents/buildTest1.xml --form json='{"parameter": [{"name":"build.xml", "file":"file0"},{"name" : "BuildType", "value" : "JSON_BUILD"}]}'

Returns:

HTTP/1.1 200 OK
Date: Wed, 04 Nov 2015 11:50:47 GMT
Server: Apache
Last-Modified: Wed, 13 Feb 2013 14:51:29 GMT
ETag: "38c26e-0-4d59c46f63e40"
Accept-Ranges: bytes
Content-Length: 0
Vary: Accept-Encoding
Content-Type: text/html

HTTP/1.1 100 Continue

HTTP/1.1 201 Created
Server: Apache-Coyote/1.1
X-Content-Type-Options: nosniff
Location: http://localhost:8080/jenkins/job/TestProject1/
Content-Length: 0
Date: Wed, 04 Nov 2015 11:51:05 GMT

Use the API to start builds as described on /job/NAME/api, i.e. /build for parameterless jobs and /buildWithParameters for parameterized jobs, and you won't have a problem.

Using /buildWithParameters does not work if you are adding a file to the request. Jenkins ignores the file unless you use /build, which I believe is already raised as a bug.

Possible, however that's a different issue, as you're writing.

So why is this API behaving differently? You're pretending to be a web browser filling out the form and submitting it. So don't be surprised to get treated as one and redirected to a URL that makes sense for the UI rather than a headless API client.

That's fine. But it doesn't really help when you're writing an application that is making use of the Jenkins API. I'm guessing it was designed to be used headlessly.

Could the API be amended to return the queue url it all circumstances where builds are being requested?

That's fine. But it doesn't really help when you're writing an application that is making use of the Jenkins API. I'm guessing it was designed to be used headlessly.

That's the problem. This is not actually the API. As I wrote before, the API as documented uses /buildWithParameters for parameterized builds. This is pretending to be a web browser.

Could the API be amended to return the queue url it all circumstances where builds are being requested?

Not as currently designed, because web browsers would get redirected to a blank 404 error page. Again, you're not actually using the API here, you're pretending to be a web browser.