4 ms·

Using custom XML is also not very REST. I would write an API in a way that uses the Accept header to demand either a HTML microformat or JSON, with the former l

Using custom XML is also not very REST. I would write an API in a way that uses the Accept header to demand either a HTML microformat or JSON, with the former laid out for web browser use.

mbreese 17y ago
Using custom XML is perfectly fine. It may not be the way you'd do it (or me for that matter), but there is nothing wrong with XML as a representation for data. In fact, this is what XML was actually designed for.
- JulianMorrison 17y ago
  XML is fine. Custom is the problem. A browser can't read it and the syntax is evident only by example.
  - gnaritas 17y ago
    Browsers aren't supposed to be able to read it. If someone is spitting out custom XML, the client is not meant to be a browser, it's meant to be an app of some sort, or an Ajax client who can read it.
    - JulianMorrison 17y ago
      If you're doing REST, browser-readability is good. It allows the API to be remotely explorable, self-explanatory, something a prospective user can test-drive with no investment in client code. Plus of course, it's a damn sight easier to test during development.
      - mbreese 17y ago
        See, there's the problem. You're trying to wrap a custom data model around HTML. HTML should model one thing: HTML documents. Browser-readability should have nothing to do with a REST API to a web service. But your browser is attempting to render an XML document, then the server probably has a MIME content-type error someplace. I do agree that it is nice to be able to test something pretty easily, but the browser is probably the wrong thing to use for this. I always end up mocking up some scripts using curl or just manually typing in commands to the HTTP server using: telnet hostname 80
        kragen 17y ago
        See, there's the problem. You're trying to wrap a custom data model around HTML. HTML should model one thing: HTML documents. This is like saying, "See, there's the problem. You're trying to express mathematics with pencil marks. Pencils should write one thing: black marks on paper." I don't see how "HTML documents" in any way constrains the semantic range of the thing being modeled.
  - bct 17y ago
    Why is JSON ok, then? Its structure would be just as custom, and a browser can't read it either. (also the entire world does not revolve around browsers)
    - JulianMorrison 17y ago
      JSON's syntax, at least, is defined. Also using JSON implies that extra stuff will be ignored and missing stuff rendered as null rather than causing the parser to crash - it's a forgiving format. Meanwhile it's a lot lighter than XML/HTML. And of course, I'm envisaging use of the "Accept" header to pick a format. Browsers ask for HTML. API users might ask for JSON.
      - bct 17y ago
        I agree with all your points, but none of them have anything to do with how "REST" something is.

Using custom XML is also not very REST. I would write an API in a way that uses the Accept header to demand either a HTML microformat or JSON, with the former laid out for web browser use.

mbreese 17y ago

Using custom XML is perfectly fine. It may not be the way you'd do it (or me for that matter), but there is nothing wrong with XML as a representation for data. In fact, this is what XML was actually designed for.

JulianMorrison 17y ago
XML is fine. Custom is the problem. A browser can't read it and the syntax is evident only by example.
- gnaritas 17y ago
  Browsers aren't supposed to be able to read it. If someone is spitting out custom XML, the client is not meant to be a browser, it's meant to be an app of some sort, or an Ajax client who can read it.
  - JulianMorrison 17y ago
    If you're doing REST, browser-readability is good. It allows the API to be remotely explorable, self-explanatory, something a prospective user can test-drive with no investment in client code. Plus of course, it's a damn sight easier to test during development.
    - mbreese 17y ago
      See, there's the problem. You're trying to wrap a custom data model around HTML. HTML should model one thing: HTML documents. Browser-readability should have nothing to do with a REST API to a web service. But your browser is attempting to render an XML document, then the server probably has a MIME content-type error someplace. I do agree that it is nice to be able to test something pretty easily, but the browser is probably the wrong thing to use for this. I always end up mocking up some scripts using curl or just manually typing in commands to the HTTP server using: telnet hostname 80
      - kragen 17y ago
        See, there's the problem. You're trying to wrap a custom data model around HTML. HTML should model one thing: HTML documents. This is like saying, "See, there's the problem. You're trying to express mathematics with pencil marks. Pencils should write one thing: black marks on paper." I don't see how "HTML documents" in any way constrains the semantic range of the thing being modeled.
- bct 17y ago
  Why is JSON ok, then? Its structure would be just as custom, and a browser can't read it either. (also the entire world does not revolve around browsers)
  - JulianMorrison 17y ago
    JSON's syntax, at least, is defined. Also using JSON implies that extra stuff will be ignored and missing stuff rendered as null rather than causing the parser to crash - it's a forgiving format. Meanwhile it's a lot lighter than XML/HTML. And of course, I'm envisaging use of the "Accept" header to pick a format. Browsers ask for HTML. API users might ask for JSON.
    - bct 17y ago
      I agree with all your points, but none of them have anything to do with how "REST" something is.