- From: Rushforth, Peter <Peter.Rushforth@NRCan-RNCan.gc.ca>
- Date: Wed, 3 Jul 2013 16:21:31 +0000
- To: "stephengreenubl@gmail.com" <stephengreenubl@gmail.com>
- CC: "public-xmlhypermedia@w3.org" <public-xmlhypermedia@w3.org>
Stephen> Mmm. Stephen> But we do allow the convention that if there is a link then Stephen> there MUST be something on a web server to which that Stephen> link resolves; i.e. broken links are Bad. Tolerating broken links is part of the design trade-off of a robust web. No amount of MUST 'legislation' can prevent them. Stephen> It seems a bit like Stephen> that to me to say that there is an implicit link between a Stephen> resource of a certain media type and another resource Stephen> algorithmically derived from the URL of that resource. I see where you're coming from. However a media type can be served by many servers, and servers 'control' their own URI space. A media type can't dictate to them what they should and shouldn't serve. Many so-called 'REST APIs' do this, but they're not actually RESTful. However, saying that a response tagged with a media type MUST be interpreted to contain a certain set of strings is not the same thing. For example, we could declare a text/foo media type like this: ### This string MUST be present. ### <content> ### This string MUST be present. ### where <content> would be any text. That only says that instances of messages of the text/foo type start and end with the ### business. I think that the media type specification could just declare those strings to be optional, having a default value declared by the media type specification. Then an equivalent (if I can stretch that term again :) text/foo message would be <content> I think the 'set of strings' could reasonably include a URI. Cheers, Peter
Received on Wednesday, 3 July 2013 16:22:00 UTC