All URLs should return HTML when not asked for application/json

[jernst]

If I buy a Thing that says it is part of the web, I expect that when I enter its URL into the browser, it shows me something human-readable. The spec says nothing about this, and chances are that implementors would return the JSON metadata, which would not be a great user experience :-)

[hobinjk]

I think this would be good to recommend but not require since it could be an issue on highly-constrained devices (especially since I think any implementer will feel pressured to provide an aesthetically pleasing UI)

[jernst]

@hobinjk I think it's the other way around :-) All IoT-style devices that I know that run HTTP run it for the purpose of providing an HTML user interface. (Most of those are extremely bad, in my experience. Would be nice if aethetitically pleasing happened -- I just haven't seen it! Embedded coding projects don't usually have designers on staff either.)

The most resource intensive part of this spec seems to be JSON parsing, not emitting either JSON or HTML -- both of those seem rather similar in terms of resource requirements?

[benfrancis]

@jernst Note that this specification is for a machine-readable representation of a web thing with a default JSON serialisation, which will have the MIME type application/td+json.

The specification provides a mechanism to link to alternative representations of the resource (such as HTML) in the links section, e.g.:

{
   "rel": "alternate",
   "mediaType": "text/html",
   "href": "/things/lamp"
 }

This type of link relation could also be provided in an HTTP header.

The HTML representation can share the same URL as the JSON representation and use HTTP content negotiation for the client to request either the JSON or HTML representation (which is what our gateway implementation does), but there is no requirement that the URLs be the the same, that the default should be HTML, or that an HTML representation be provided.

[jernst]

@benfrancis I totally understand that it "could" return HTML, and I'm asking that the spec state that is "should" return HTML in this case. The additional work to implement this, and the additional computation/memory/etc requirements are minimal compared to the usability advantages to those people who have heard "it's part of the web, yea!" and have not read the specs (once deployed, IMHO, the vast majority of people). I'm using the popular definition of "web" meaning "something that I can look at in my browser". Otherwise the marketing ("web"!) is a bit pointless IMHO :-)