4 ms·

Two reasons that I can see... If the server generates custom mimetypes, clients have to ensure they "Accept:" the correct mimetype for every request. And if yo

Two reasons that I can see... If the server generates custom mimetypes, clients have to ensure they "Accept:" the correct mimetype for every request. And if you have multiple data types (and you will have multiple data types), then this "Accept:" header will vary for every request. Getting this right is an irritant to client developers with no actual benefit to them, and a great potential source of bugs. Much easier is if the client can just send "Accept: application/json" or "Accept: application/xml" for every request. If the server generates custom mimetypes, and you update your API to v2 which produces an article listing in an incompatible format, you either have to introduce a version number into your mimetype (which seems messy and pointless busywork), or stick with the same mimetype and accept that your custom mimetypes aren't actually particularly meaningful as their meaning can change substantially over time (so why did you have them in the first place?) Much easier is if the server had just used "Content-Type: application/json" or "Content-Type: application/xml" which will always be correct.

arethuza 15y ago
So if you don't communicate that the version of the structure of your response has changed through the Content-Type, where would you do it?
icebraining 15y ago
If the server generates custom mimetypes, clients have to ensure they "Accept:" the correct mimetype for every request. No, he doesn't. First, the server can send whatever it wants - nothing breaks if you reply with your custom media type to a generic "application/json" request. Second, even if you want to be correct, that's what wildcards are for: the client can simply send always the same header: Accept: application/*+json If the server generates custom mimetypes, and you update your API to v2 which produces an article listing in an incompatible format, you either have to introduce a version number into your mimetype (which seems messy and pointless busywork), I still don't get what's the problem with changing a string. I think you're using a bad framework.
- waitwhat 15y ago
  I doubt that sending a mimetype which the client has said it can't accept would be on anyone's list of best practices. This is a good point, though, not sure why it escaped me: Accept: application/*+json I think you're using a bad framework. Probably. This isn't why, though.
deleted 15y ago
[deleted]

arethuza 15y ago

So if you don't communicate that the version of the structure of your response has changed through the Content-Type, where would you do it?

icebraining 15y ago

If the server generates custom mimetypes, clients have to ensure they "Accept:" the correct mimetype for every request. No, he doesn't. First, the server can send whatever it wants - nothing breaks if you reply with your custom media type to a generic "application/json" request. Second, even if you want to be correct, that's what wildcards are for: the client can simply send always the same header: Accept: application/*+json If the server generates custom mimetypes, and you update your API to v2 which produces an article listing in an incompatible format, you either have to introduce a version number into your mimetype (which seems messy and pointless busywork), I still don't get what's the problem with changing a string. I think you're using a bad framework.

waitwhat 15y ago
I doubt that sending a mimetype which the client has said it can't accept would be on anyone's list of best practices. This is a good point, though, not sure why it escaped me: Accept: application/*+json I think you're using a bad framework. Probably. This isn't why, though.

deleted 15y ago

[deleted]