Hacker News new | ask | show | jobs
Show HN: What an API is for non technical people (isaacs-journal.herokuapp.com)
11 points by inoda 2524 days ago
5 comments

This is a good analogy but the description is really one of a REST API. An API in general can take a form other than one or more endpoints. An API is a means of consuming a program that is not a GUI or CLI but that needs to be accessed through code. Basic front-end development is wrapping code that consumes an API in a GUI. There are dozens of Javascript APIs built into browsers for code that runs locally.

https://developer.mozilla.org/en-US/docs/Web/API

I usually start with saying that an Application User Interface describes how a user (i.e. person) uses the website to get information while an Application Programming Interface describes how another program get information from an application.
If you want to make APIs simpler, a project we have on the backburner is to start getting adoption for folks to offer Tree Notation apis.

In the 2000's APIs were in XML/SOAP/WSDL and were a total pain. JSON changed all that.

In the 2020's Tree Notation is going to do something similar.

Here's the idea from 2014: https://www.youtube.com/watch?v=DV4Nv23bBwQ (Tree Notation was called "Space" back then)

Here's the current Tree Notation project: http://treenotation.org/

Looks very similar to YAML. I'm not sure this will replace JSON though, for one specific reason.

The more levels of nesting you have in the Tree Notation file, the more of the file's space is ... well white space characters. JSON doesn't have this problem, as spaces are not crucial to the structure of the data.

This means that although there's less characters, you cannot minify the Tree Notation, like you can with JSON (as indentation is crucial for representation in the tree)

I could be wrong though...

> The more levels of nesting you have in the Tree Notation file, the more of the file's space is ... well white space characters. JSON doesn't have this problem, as spaces are not crucial to the structure of the data.

This is a good thought, and a theoretical problem I used to think about, but in practice it hasn't really come up. In practice what has happened, is that anytime things started getting deeply nested, it was a sign that the Tree Language should be refactored so things could be made flatter.

> This means that although there's less characters, you cannot minify the Tree Notation, like you can with JSON (as indentation is crucial for representation in the tree)

The other thing to keep in mind that JSON is almost always GZIPPED before it is actually sent over the wire, and the compression characteristics of zipping/minifying TN are as good (if not better--I hope someone some day will do the research here), than JSON.

Interesting, I hadn't considered GZipping, that probably would be much smaller than JSON in that case. Maybe Tree Notation has a chance after all.
With the same analogy, UI is probably the dog trainer who knows all the commands that the dog understands. You tell the trainer what you want the dog to do and trainer issues the right command.
Ha, good example!!