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

191–200 of 225 posts

Re: JSON Feed

#191

Post by stephenr »

icebraining wrote: post #189
stephenr wrote: post #177

Earlier quoted context omitted.

> XML is to JSON as SOAP is to REST That's true. Both XML and SOAP are well defined, and well structured. JSON and REST are both marginally defined, and thus we see constant incompatible/incomplete implementations, or weird hacks to overcome the shortcomings. > we have better tools now I think "the cool kids are cargo-culting something newer now" is probably more accurate.

Nitpick: REST is very well defined. It's not just a protocol, like some people insist. Other than that, fully in agreement.

Rest is effectively a concept, and its up to developers to follow the rules it sets.

You can't take your codebase, add some glue code to a REST module, and know that it will be usable by any other REST consumer/client, because no one follows the guidelines exactly the same way.

Re: JSON Feed

#192

Post by icebraining »

lucideer wrote: post #106
russellbeattie wrote: post #98

For anyone who's tried to write a real-world RSS feed reader, this format does little to solve the big problems the newsfeeds have: * Badly formed XML? Check. There might be badly formed JSON, but I tend to think it'll be a lot less likely. * Need to continually poll servers for updates? Miss. Without additions to enable pubsub, or dynamic queries, clients are forced to use HTTP headers to check last updates, then do…

> Need to continually poll servers for updates? Miss. Without additions to enable pub sub, or dynamic queries, clients are forced to use HTTP headers to check last updates, then do a delta on the entire feed if there is new or updated content. This is backwards, imo. The advantage of polling over pub sub is that all complexity is offloaded to the client. This comes with its own set of problems (inefficiency of reinve…

Plus, you can always reuse PubSubHubBub (now WebSub[1]), which is already used in RSS/Atom feeds to provide optional subscribing to updates if both the server and client support it.

[1] https://www.w3.org/TR/websub/

Re: JSON Feed

#193

Post by chriswarbo »

hayleox wrote: post #88
mindcrime wrote: post #2

Do we really need this? Atom is fine for feeds. Avoiding XML just for the sake of avoiding XML, because it isn't "cool" anymore is just dump groupthink. If this industry has a problem, it's FDD - Fad Driven Development and IIICIS (If It Isn't Cool, It Sucks) thinking.

To be honest, I'm really excited about the prospect of JSON based feeds. Right now, there's no easy way to work with Atom/RSS feeds on the command-line (that I know of anyway), which is something I often wish I could do. With a JSON feed, I can just throw the data at jq ( https://stedolan.github.io/jq/ ) and have a bash script hacked together in 10 minutes to do whatever I want with the feed.

There are a few nice XML processing utilities. I tend to use xmlstarlet and/or xidel. This lets me use XPath, jQuery-style selectors, etc.

I agree that jq is really nice though. In particular, I still find JSON nicer than XML in the small-scale (e.g. scripts for transforming ATOM feeds) because:

- No DTDs means no unexpected network access or I/O failures during parsing

- No namespaces means names are WYSIWYG (no implicit prefixes which may/may not be needed, depending on the document)

- All text is in strings, rather than 'in between' elements

- No redundant element/attribute distinction

Even with tooling, these annoyances with XML leak through. As an example, xmlstarlet can find the authors in an ATOM file using an XPath query like '//author'; except if the document contains a default namespace, in which case it'll return no results since that XPath isn't namespaced.

This sort of silently-failing, document-dependent behaviour is really frustrating; requiring two branches (one for documents with a default-namespace, one for documents without) and text-based bash hackery to look for and dig out any default namespace prior to calling xmlstarlet :(

http://xmlstar.sourceforge.net

http://www.videlibri.de/xidel.html

Re: JSON Feed

#194

Post by josteink »

mattmanser wrote: post #185
dabeeeenster wrote: post #182

Earlier quoted context omitted.

What language are you using that doesn't have a working XML parser? REALLY?

He said appropriate XML parser. All languages have XML parsers, it's more that a lot suck, they might have weird concepts you have to use, or are constantly tripping you up with namespaces, or make it really hard to write xpath queries.

> or are constantly tripping you up with namespaces

You mean requires that you understand the XML format you are working with? Oh noes!

Namespaces exist, just about everywhere in the world of programming, and they do so for a reason.

is not the same as just like http://bar.com is not the same as http://bar.foo.com.

If that's putting the bar high, I really think I may be suffering a huge disconnect from the rest of my peers in terms of expected capabilities.

Just because JSON doesn't have namespacing-capabilities at all, doesn't make it a worthless feature. It's actually what gives you the eXtensibility in XML. As a developer I expect you to understand that.

(And I wonder how long time it will take before the JS-world re-implements this XML-wheel, while again doing so with a worse implementation)

Re: JSON Feed

#195

Post by jancsika »

josteink wrote: post #194
mattmanser wrote: post #185

Earlier quoted context omitted.

He said appropriate XML parser. All languages have XML parsers, it's more that a lot suck, they might have weird concepts you have to use, or are constantly tripping you up with namespaces, or make it really hard to write xpath queries.

> or are constantly tripping you up with namespaces You mean requires that you understand the XML format you are working with? Oh noes! Namespaces exist, just about everywhere in the world of programming, and they do so for a reason. is not the same as just like http://bar.com is not the same as http://bar.foo.com . If that's putting the bar high, I really think I may be suffering a huge disconnect from the rest of m…

> (And I wonder how long time it will take before the JS-world re-implements this XML-wheel, while again doing so with a worse implementation)

I'm going to guess never. I'm also going to guess that there isn't a single flamewar in the entire history of JSON where someone was trying to figure out how to implement anything close to XML namespaces in JSON. And by "close", I mean something that would require changes to JSON parsers and/or downstream APIs to accommodate potentially bipartite keys.

Re: JSON Feed

#196

Post by martin-adams »

foota wrote: post #115
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 seems that all this spec is, is a structure for an api response. I don't see why it should have a different media type.

I don't believe it should be just application/json because it's a specific format of json. There could be multiple json representations of the feed other than jsonfeed that the server supports and the client could define which ones they Accept.

So the server could support all of the following:

application/jsonfeed

application/rss+xml

application/atom+xml

Who knows, maybe RSS and ATOM could be represented in JSON and have the following mime types:

application/rss+json

application/atom+json

If it's just an API response, and it is your API for an application called Widget Factory, then you can, if you want, have your own format:

application/vnd.widgetfactory+json

Generally, defining such a mime type should have some specification describing it otherwise no client can reliably implement a compatible client. Jsonfeed have proposed that specification.

Re: JSON Feed

#197

Post by paulddraper »

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

> There is no requirement or guarantee that an array or an object are the top-level value in a JSON document.

Alas, if only that were true.

RFC 4627:

> A JSON text is a serialized object or array. The MIME media type for JSON text is application/json.

RFC 7159:

> A JSON text is a serialized value. Note that certain previous specifications of JSON constrained a JSON text to be an object or an array. Implementations that generate only objects or arrays where a JSON text is called for will be interoperable in the sense that all implementations will accept these as conforming JSON texts.

IIRC, Ruby's JSON parser was written to be strictly RFC 4627 compliant, and yields a parser error for non-array non-object texts.

Since JSON isn't versioned so no one has any idea what "JSON" really means, or what "standard" is being followed.

Re: JSON Feed

#198

Post by josteink »

jancsika wrote: post #195
josteink wrote: post #194

Earlier quoted context omitted.

> or are constantly tripping you up with namespaces You mean requires that you understand the XML format you are working with? Oh noes! Namespaces exist, just about everywhere in the world of programming, and they do so for a reason. is not the same as just like http://bar.com is not the same as http://bar.foo.com . If that's putting the bar high, I really think I may be suffering a huge disconnect from the rest of m…

> (And I wonder how long time it will take before the JS-world re-implements this XML-wheel, while again doing so with a worse implementation) I'm going to guess never . I'm also going to guess that there isn't a single flamewar in the entire history of JSON where someone was trying to figure out how to implement anything close to XML namespaces in JSON. And by "close", I mean something that would require changes to…

You never know. This is what they said about schemas too not many years back.

Re: JSON Feed

#199

Post by donohoe »

yoz-y wrote: post #188
cocktailpeanuts wrote: post #93

Doesn't Wordpress already have something like this? http://v2.wp-api.org/ I don't understand why suddenly people treat this like something that uniquely solves a problem. Maybe I'm missing something?

This format is more akin to RSS than to a programmatic rest API. The main goal is to be able to avoid the pitfalls of parsing Atom and RSS feeds. Both Brent Simmons and Manton Reece are quite active in making decentralized alternatives for self publishing for which RSS is the current backbone.

Parsing RSS and Atom feeds is a solved problem, no?

Re: JSON Feed

#200

Post by yoz-y »

donohoe wrote: post #199
yoz-y wrote: post #188

Earlier quoted context omitted.

This format is more akin to RSS than to a programmatic rest API. The main goal is to be able to avoid the pitfalls of parsing Atom and RSS feeds. Both Brent Simmons and Manton Reece are quite active in making decentralized alternatives for self publishing for which RSS is the current backbone.

Parsing RSS and Atom feeds is a solved problem, no?

JSON Feed is a new solution for the problem already solved by RSS or Atom. It makes it easier to develop new publishers and consumers. It also tackles the main problems with these two formats, e.g.: no realtime subscriptions, mandatory titles which are a pain for microblogs, potential security problems with XML and so on.

Like somebody somewhere has written: If no one had ever reinvented the real wheel - our cars would be rolling around on big wooden logs

Post reply on HN