API v2: Malformed JSON bodies returned on 400s

API
1

When calling v2 of the REST API to create a context, if that context already exists, I get a malformed JSON response:

{:message "A context named terraform-test already exists."}

What should be returned:

{"message": "A context named terraform-test already exists."}

Note that the colon proceeds message and that the key is unquoted. My request sets Content-Type and Accept-Type to application/json. The response has no Content-Type set.

Since my code is expecting a JSON response per the documented behavior, this ends up causing a somewhat cryptic JSON parsing error for the user:

invalid character ':' looking for beginning of object key string
2

Even when the context is successfully created, no Content-Type header is set in the response. The response data is valid JSON despite the missing header:

{
	"name": "terraform-test",
	"id": "aa7c62cb-2a89-40c4-aa38-67f694bca4c2",
	"created_at": "2021-03-13T00:34:11.031Z"
}
3

The missing Content-Type header is not limited to the Contexts API. When calling GET /projects/{slug}, I also get back valid JSON, but without a Content-Type: application/json header.

4

Hello @bendrucker

Thanks for raising this issue with us. Are you setting the header Accept: application/json in your request? If not, then the behavior you’re experiencing is expected.

As noted here in our v1 docs if you don’t set the Accept header we will return Clojure EDN format and the content type will be set to plain. It seems that this information has been omitted from our more recent API docs, and i’ve raised an issue for us to improve our messaging around this.

Can you add the Accept header to your requests and let me know if you’re still having issues with the response?

5

Thanks! A collaborator on GitHub seemed to confirm that adding an Accept header resolved the issue. I’ll check myself, but that seems to be the issue.

I was hoping to use this in place of an official API client for Go:

That sets Accept-Type but not Accept. It also checks for Content-Type before trying to parse the response as JSON, which is how I spotted the missing Content-Type header. I’ve copied that into our project and will tweak it a bit until it works correctly.

6

Confirmed that setting Accept results in expected behavior, including a Content-Type with the response. Thanks!

2 Likes
7

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.