1. 11

  2. 7

    Relevant xkcd: https://xkcd.com/1481/

    1. 3

      I am a fan of this idea, but need to ask: why not support both as a syndication format? JSON isn’t difficult to parse these days, and if you are using RESTful best practices, the format of the response can be changed based on a request parameter.

      1. 6

        For anyone not familiar with the http spec: the Accept header is there for this. Changing the URL is rebuilding stuff that’s already in the protocol and adds unnecessary coupling between client and server.

      2. 3

        This article makes no sense to me, what the hell does this have to do with microservices?

        1. 2

          What problem is this solving exactly? It kinda seems like the author is maybe just rediscovering XML as a transport and noting that they can fudge it to be human readable by picking HTML compatible tags? Maybe?

          1. 3

            It means that your API can be browsed by a human using Firefox. It also inlines documentation about what fields to set for creating new resources via forms.

          2. 2

            I really hope this takes off. XML was such a turn off to me and JSON makes me want to stab my eyes out. HTML even at its most verbose is still better than XML and JSON in my opinion.

            1. 1

              How do both parties agree upon exchanging data such as binary data, dates, and so on, where there might be multiple valid textual representations? The benefit of a spec is that it constrains the design space on uninteresting problems like data interchange so you can focus on more important things.

              1. 2

                Standard Microformats are a thing; I’d say this is an easier problem to solve in HTML than in json

                1. 1

                  To be fair, JSON doesn’t address binary data or dates directly, it would need to be agreed upon by both parties. That seems orthogonal to whether we use JSON or HTML5 as the data serialization format.

                2. 1

                  I can’t tell if this is an elaborate troll, or a very uninformed, but serious article. The fact that this article makes no reference to XML, and the technology that exists in that world is baffling.

                  What is the strategy here for parsing incoming documents? Why are HTML based micro formats better than XML with a DTD? This doesn’t make sense to me, but I realize that this idea is “fresh”, and I am being dismissive, so…

                  1. 1

                    The strategy here is that formatting your data as HTML may well be enough when you control the client side Javascript and provides benefit to the user when you don’t. This is an improvement on using JSON, as with JSON you need to control the client side Javascript, but don’t have a ‘fallback’ for the user. The tricky bit is in that you need to parse the data you want to get at from the HTML provided, but that can be done by leveraging the HTML parser that is in the browser and navigating the (probably disconnected) DOM nodes that you get from it.

                    Combining this with the Accept: header and rendering HTML, JSON and e.g. RDF for objects that your app exposes forces you to think harder about how to expose your objects, and allows you to take advantage of all the work done on e.g. Linked Data (SPARQL comes to mind).

                    1. 1

                      The only benefit I see here, is potentially during development, when you’re trying to discover how to utilize an API. And, while that might be OK, you’d almost certainly be better served by building an API on top of existing tooling (say, e.g. swagger), that give you benefits like standardized documentation and an API console.

                      But, I don’t build front end services, so maybe I’m missing something key.