12 ms·
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
by 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 agoIf 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 agoSee, 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 agoSee, 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.