I read a lot of RFCs and drafts for media types lately and what strikes me reading this spec is the very liberal use of MUST which seems to me like an unnecessary violation of the robustness principle, that Jon Postel introduced first in RFC761 (TCP). Mike Amundsen describes in his book 'Building Hypermedia APIs […]':
Media type designers should keep Postel in mind. Designers can make
supporting the Robustness Principle easier for implementor by keeping the
number of MUST elements in the compliance profile to a minimum. The fewer
MUST elements implementors need to support, the more likely it is that they
will be able to craft compliant representations using that media type.
Postels law is the worst kind law ever made in IT. Take a look at how many security bugs that comes from being 'accepting' of bad HTML/CSS/Javacscrip/PDF files.
Be a nazi in what you accept, fail loudly and early enough and there will be no problem for the user to correct his error - it is only when you 50000 php pages full of echo statements that you can't change. If it had complained when he made the first, he wouldn't be in that situation now.
And don't tell me that nobody would use it then. C++, C# and Java are the top most used languages and they are all anal-retentive.
Indeed. In my experience, looser requirements in this kind of thing just leads to tears on the part of client and server implementations. I'll happily reduce some of the MUSTs to SHOULDs or MAYs if it makes sense for the communication channel to consider them optional.
That's great to hear. One particular example which I found needlessly strict is this:
The request MUST contain a Content-Type header whose value is
application/json. It MUST also include application/json as the only or
highest quality factor.
It makes sense for fully compliant implementation to have those headers, but they way I understand MUST here is that a server would reject any request without them.
