[mikewarot]

Interesting ideas. I think that anytime you pass data between code bases, you're going to end up converting it to/from json, xml, or some other intermediate format. It's a cost that I don't think we can avoid.

If you think outside the centralized server, I could fairly quickly implement my fragment of a distributed twitter. It's a matter of declaring a few objects/types, and writing code to do CRUD for my locally hosted parts, replicate those to some publicly accessible file host/web page, and them write an engine to scan all the other sites where the people I follow publish their data.

Two things that can't be replicated:

  1> blocking of users. Once data is public, you don't get it back.
  2> anonymous comments or replies. This would require scanning all replies, even of people you don't follow. It's possible this could be a service from a 3rd party aggregator.

What I'm seeing most of all is a glimmer of what is possible if you don't have to worry about security, and just solve problems. The walled gardens are a result of security issues, the network effects are a result of the small number of walled gardens. If you can tell your computer to do function X with data Y, and there is NO possible way it could get hijacked or confused into doing Z, then this could work.

[izuchukwu]

The computer doesn’t have to do these locally—there’s no reason this couldn’t be implemented as a thin client.

I agree that data has to be converted, but I don’t agree that it has to be as manual as it is today. Consider this: In addition to your API, a second JSON file gets generated that describes the schema of the first. On the consuming developer’s end, their language & IDE uses that schema to let you call APIs or RPCs exactly like they were local functions.

[mikewarot]

I've been hiding in a cave for a long time, metaphorically. I've never had to deal with JSON or XML for that matter... I'm shocked that there's no metadata with type information at the top of either one? That's insane... everything is a gosh darned string? Ick!

If you have function calls without type information, anything can happen, a function call could result in your neighbor's pool being drained, and your bank balance being sent to Belize.

In Pascal, you have to have a type before you can declare a variable. This little inconvenience saves you from an entire class of errors.

If I'm going to import a random file from the internet, I have to be sure of the type of data in it before I'm going to touch it with a 10 foot pole (or barge pole in Britain).

I had no idea people got so foolish.

Back to your idea, of course there should be type information, either as a separate file, or at the head of the file.

In Pascal, I'd have the import routine check it against the RTTI (run time type information) of the local native structure as part of the import, and throw errors if there were problems. On export, the RTTI could create the type header file/section of JSON.

[izuchukwu]

There are ways to specify schemas for JSON and XML. However, for APIs, XML's gone and schemas for JSON never caught on.

JSON is a serialized JS object, which itself is untyped, so anything can be in any order. Think NoSQL databases. This simplicity gave JSON the ability to be adopted by a multitude of languages very, very quickly. Foolish, maybe, but you could build Stripe on it.

GraphQL, an emerging API standard, does feature schemas, and its rise is bringing types back to APIs. It can be a bit more work to implement than JSON, though.

It's the classic complex-simple-complex pendulum swing. We're not done, either.