The client consistently makes requests with the accept header of 'application/json' and content-type of 'application/json'
Yes, this is the correct thing to do, but doesn't mean the vendor cares. While I totally understand your frustration, because I also think a JSON service should always give a JSON response but there are many examples where that's the not the case.
Throughout the project this same practice has been applied across two different vendors and two different services. I found myself having to justify why the services needed to be changed. The vendors stated that the client should cope with this and even my REST library of choice has been questioned (RestEasy) because it doesn't cope with this by default 'out the box'.
Well, I have to agree with the vendor. It's their service and as long as they document clearly the special cases for using it, then you can't really impose that they change it. It's a disadvantage for them as developers will be slow to adopt their API, and if they listened to what the developers need then they would change it, but sadly there is no rule that they must follow standards.
The question is am I missing something?
Request headers mean nothing unless they are interrupted correctly on the other end. I know that if I develop a web API using PHP, then to hell with the request headers. I can respond with whatever I want. Whereas, a service configured in IIS with C# offers much easier handling of request headers, their type and handling the response type. It has a lot to do with the tools the vendor used to build the API.
I'm I being pedantic about this?
Yes and No. I have developer friends who would be unable to move past this. They would become so fixated by the problem and unable to proceed with other tasks until the API works the way they expect it to work. Now that's being pedantic.
It's a problem because the vendor has created "more work" to complete your tasks. Anyone would be frustrated by that. I know I would be.
Is it OK to have a JSON API that doesn't have a content-type of application/json in this scenario?
Absolutely, but it's not a good practice.
A client can only tell the server what the context-type of a
request is. It has no ability to enforce a content-type for the
response. The client can only inform the server that it will
accept a collection of possible content-types.
Header Field Definitions
The Accept request-header field can be used to specify certain media types which are acceptable for the response. Accept headers can be used to indicate that the request is specifically limited to a small set of desired types, as in the case of a request for an in-line image.
It's possible for a client to request an image of
image/jpeg, but the server responses with
text/html and a status code of
404 if the image was not found. Servers can also respond incorrectly. There are many Wordpress websites out there that respond with
text/html and status code
200 for files not found pages.
Now that is all BAD practice on the part of the server. What I'm trying to tell you is that it's absolutely possible, and happens often. People don't know what they are doing when they configure these things.
References would be appreciated. How do you resolve this situation from a commercial point of view?
I've run into this problem on a few projects. You
post JSON data to the server and it gives back either a JSON or HTML response.
It really isn't a big deal to know which type was in the response. If the first character is
[ you can assume JSON. If it's
< you can assume HTML. That's how I've handled it in the past. Sometimes the programmer who wrote the API knows jack all about HTTP headers. Everything comes back as
text/html responses. If you are lucky they have Apache configured to default to
text/plain which can sometimes help.
These problems exist and will continue to exist far into the future. Server to server communication is by far an unregulated activity. There is no governing body that will kick out a vendor from a union for a server that gives bad HTTP responses.