Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JSON Feed

jsonfeed.org

Post reply on HN
Print view View original

121–130 of 225 posts

Re: JSON Feed

#121

Post by vanderZwan »

jawns wrote: post #51

> It's at version 1, which may be the only version ever needed. Wow. Now that's confidence. Have you ever read the first version of a spec and thought, "That's just perfect. Any additional changes would just be a disappointment compared with the original"?

In all fairness, they're taking a more or less solved problem (feeds), so they don't really have to figure things out there, and they're porting this established solution to a very well-established technology (JSON), so also don't really have to figure stuff out in that sense either.

As far as scenarios where it's feasible to get the answer right the first time go, this is a reasonably realistic one.

EDIT: Also, if you scroll to the bottom of the page you can see they have let a whole bunch of people look at the spec before releasing it, so there has been at least some peer review.

Re: JSON Feed

#122

Post by debaserab2 »

anshou- wrote: post #41
mstade wrote: post #26

> JSON Feed files must be served using the same MIME type — application/json — that’s used whenever JSON is served. So then it's JSON, and I'll treat it as any other JSON: a document that is either an object or an array, that can include other objects or arrays, as well as numbers and strings. Property names doesn't matter, nor do order of properties or array items, or whatever values are contained therein. Please do…

It's worth pointing out that any valid JSON value is a valid JSON document. There is no requirement or guarantee that an array or an object are the top-level value in a JSON document. "I am a valid JSON document. So is the Number below, and in fact every line below this line." 4 null

Beware that many JSON parsers don't agree with this, although your interpretation is the correct interpretation of the spec. Some parsers will only accept either an array or object. If you're building a JSON endpoint you'll be safest returning either an array or object.

Re: JSON Feed

#123

Post by donohoe »

I have grave concerns that this publishing format is delivered to us by two people that, as far as I can see, have limited to zero publishing background.

That said, they're being responsive to questions in Issues, so I remain optimistic.

Re: JSON Feed

#124

Post by rspeer »

mstade wrote: post #26

> JSON Feed files must be served using the same MIME type — application/json — that’s used whenever JSON is served. So then it's JSON, and I'll treat it as any other JSON: a document that is either an object or an array, that can include other objects or arrays, as well as numbers and strings. Property names doesn't matter, nor do order of properties or array items, or whatever values are contained therein. Please do…

Should this web page have been served as `text/hacker-news-comment-thread+html`?

Re: JSON Feed

#125

Post by floatboth »

jjawssd wrote: post #35
bastawhiz wrote: post #18

Earlier quoted context omitted.

Consider XML entity bombs. You need to explicitly tell your XML parser not to follow the spec to prevent malicious sources of XML from crashing your application. XML also has a lot of room for syntax errors, with many types of tokens and escape rules. JSON, by comparison, does not.

> XML also has a lot of room for syntax errors, with many types of tokens and escape rules. JSON, by comparison, does not. Parsing JSON is a minefield. Yellow and light blue boxes highlight the worst situations for applications using the specified parser. Take a look at how a bunch of parsers perform with various payloads: http://seriot.ch/json/pruned_results.png "JSON is the de facto standard when it comes to (un)se…

None of these issues are as bad as the XML ones. You generally don't need "defusedjson" like you need https://pypi.python.org/pypi/defusedxml

]> ⅇ

Re: JSON Feed

#126

Post by sacheendra »

mstade wrote: post #66
moduspol wrote: post #36

Earlier quoted context omitted.

It's more than JUST library support. It's also that JSON deserializes into common native data types naturally (dictionary, list, string, number, null). You can deserialize XML into the same data types, but it's not anywhere near as clean because of how extensible XML is. That's a big part of what's made JSON successful.

Right, but you inevitably end up with boilerplate "massage" code around your data anyway. Case in point: dates, any number that isn't just a number e.g. currencies or big numbers, URLs, file paths, hex, hashes. Basically any type that carries any kind of semantics beyond array, object, string, number, or null will require this boilerplate, only that your data format has no way of describing them except for out-of-ban…

IMHO the boilerplate code is much easier to read than understanding the nuances of XML if I have to read a document.

{"type":"currency", "unit":"euro", "amount": 10}

feels easier to understand than

10

Re: JSON Feed

#127

Post by [deleted] »

mstade wrote: post #26

> JSON Feed files must be served using the same MIME type — application/json — that’s used whenever JSON is served. So then it's JSON, and I'll treat it as any other JSON: a document that is either an object or an array, that can include other objects or arrays, as well as numbers and strings. Property names doesn't matter, nor do order of properties or array items, or whatever values are contained therein. Please do…

[deleted]

Re: JSON Feed

#128

Post by jameshart »

anshou- wrote: post #41
mstade wrote: post #26

> JSON Feed files must be served using the same MIME type — application/json — that’s used whenever JSON is served. So then it's JSON, and I'll treat it as any other JSON: a document that is either an object or an array, that can include other objects or arrays, as well as numbers and strings. Property names doesn't matter, nor do order of properties or array items, or whatever values are contained therein. Please do…

It's worth pointing out that any valid JSON value is a valid JSON document. There is no requirement or guarantee that an array or an object are the top-level value in a JSON document. "I am a valid JSON document. So is the Number below, and in fact every line below this line." 4 null

Actually actually... the JSON spec doesn't define the concept of a JSON document. Neither http://www.json.org/ nor http://www.ecma-international.org/publications/files/ECMA-ST... actually specifies that a JSON 'document' is synonymous with a JSON 'value'.

Now it's also true that JSON doesn't specify an entity that can be either an object or an array but not be a string or a bool or a number or null. So it's kind of true that JSON doesn't say that an object or array are valid root elements.

But JSON also says "JSON is built on two structures" - arrays and objects. It defines those two structures in terms of 'JSON values'. But it's a reasonable way to read the JSON spec to say that it defines a concept of a 'JSON structure' as an array or object - but not a plain value. And then to assume that a .json file contains a JSON 'structure'.

Basically... JSON's just not as well defined a standard as you might hope.

edit: And now I'm going to well actually myself: Turns out https://tools.ietf.org/html/rfc4627 defines a thing called a 'JSON text' which is an array or an object, and says that a 'JSON text' is what a JSON parser should be expected to parse.

So - pick a standard.

Re: JSON Feed

#129

Post by DougWebb »

mstade wrote: post #97
tghw wrote: post #81

Earlier quoted context omitted.

True, but that's also true of any XML, RSS, Atom, HTML, etc. Websites abuse HTML all the time, and there's nothing saying that just because something is transferred with application/atom+xml that it will be valid or follow the spec. It's more of a social agreement. If you get a JSON object from a place you expect a JSON Feed and it has a title and items, then it'll probably work, even if it omits other things.

So we can ditch media types altogether then? What's the point of having actual contracts if all we need is a hand shake and a wink? We're not talking about malformed data here, that's something different entirely and yes – it happens all the time. We're talking about calling a spade a spade. If it's JSON your program expects then I should be able to throw any valid JSON at your program and it should work. Granted, it…

If it's JSON your program expects then I should be able to throw any valid JSON at your program and it should work.

That's not a valid argument, because JSON is just a serialization format for an arbitrary data structure. You can't throw any arbitrary data structure at any program that accepts data and expect it to be able to accept it. Every program that accepts input requires that input to be in a specific format, which is nearly always more specific than the general syntax of the format. And aside from programs that make strict use of XML schemas, they pretty much all use the handshake-and-wink method for enforcing the contract. (Or to put it another way: documentation and input validation.)

My take on the author's approach is that the content-type is specifying the syntax of the expected input, and the documentation specifies the semantics and details of the data structure. In that respect, the program works like most other programs out there.

Re: JSON Feed

#130

Post by weberc2 »

jwilk wrote: post #117
weberc2 wrote: post #108

Earlier quoted context omitted.

Yikes, you didn't even make it to the second sentence. > JSON is simpler to read and write, and it’s less prone to bugs.

From the HN guidelines: Please don't insinuate that someone hasn't read an article.

My mistake for phrasing my point in a manner that violates HN guidelines. I tried to edit, but I missed the window. At any rate, my point stands.
Post reply on HN