API's were always how software has been built .. Web API's, on the other hand ...

For software designed to be used by other developers, sure. For software in general, that's not my experience.

> Web API's, on the other hand ...

The ellipses suggests a natural conclusion, but none come to mind. Do you mind completing the thought?

No, they're becoming so smart they don't want to reinvent the wheel for the nth time.

I take issue with this. If the single most important step to converting developers to /permanently/ using your API isn't something like scalability, security, performance, or functionality, there is something wrong with this world.

Just because you get more people to succeed in trying your API at the beginning, if it doesn't work for their use case over the long haul they are just going to leave and do something else: the key word is then "permanently".

In comparison, Amazon's APIs are often ludicrously complex. Even if you try to use Amazon's client libraries, they are often ludicrously complex, requiring you to construct object factories to get arguments even for the most common request paths.

But, by and large, Amazon's services don't stop working when you get too much data, have well-thought-out authorization mechanisms, have never become randomly slow as lots of users sign up for the service, and are sufficiently flexible to support many different kinds of tasks.

The fact that the first time I sat down and used Amazon's APIs it took me a while to get them working (and that some APIs from them I still haven't gotten around to learning all the properties of) is then irrelevant: I could tell they would do what I wanted once I figured it out, and I have never been disappointed.

Meanwhile, I've come across tons of random startups, often that have websites that are a "little too Web 2.0" (normally a negative indication for an API provider, btw), whom have APIs (or libraries, or daemons, or services, or programming languages) that are great at first but actually sucked.

(I mostly felt the need to make this comment, btw, due to someone else in this thread seemingly arguing against OAuth because, despite being secure, it made the API sufficiently complex that they could no longer use curl with it: that is the opposite method from how you should be choosing an API.)

This quite fundamentally flawed. In many cases, the APIs are the most important and hardest work, and the implementation is arbitrary.

This signals a usability fail in my mind.

I don't, I can just teach my backend to process /api. The backend is running code under my control anyway. This seems like one of the least difficult "problems" to solve in any non-trivial codebase.

What exactly are you saying?

Do you really think no-one has tried that?

The API definitions (even the good ones, like Azure) do not contain sufficient information to be able to build a declarative tool. Google seem to view their internal annotations about what is mutable or not as some kind of competitive advantage (bizarre). The AWS API is wildly poorly specified for building anything except 1-1 API wrappers. (Cloud Control improves it, but covers few important resources).

I agree with the article. As we build more complex products we need to be more specialized and work together.

Maybe not the case if one is working at a startup trying to cobble something together that looks like a working product by customers and investors.

It stems from APIs having bugs, and not being consumed by the writers. The flows were badly designed because they would never write a client against the API.

By making the web be a client to the API, the design, quality and maintenance of the API is very much to the fore. It also allows the implementations to evolve at their own speed, which helps a lot with maintenance, especially when one adds a mobile client, or changes some other UX flow... it becomes easier to work through things.

So yes, I agree... slower to get started and 2 codebases. But, so many advantages, higher quality, and lower maintenance costs that arise from the kind of short cuts that a single monolith codebase makes possible.

They don't have public APIs you mean. With a bit of effort you could reverse engineer what their app is doing. The real pain is maintaining it, keeping up with changes. Hence why nobody bothers.

Is it, though?

The only argument I see is that an API can be misused. There are ergonomics debates we can have about it, but a user intentionally abusing an API wanting to do something that's completely wrong is hardly indication the API is broken.

The intro video doesn't seem like anything is being made any easier, other than hiding a few of the templated bits away from the developer.

But the developer still has to understand what all this stuff MEANS. You need to understand REST, GET, PUT, REPL and any other acronyms that are involved in API development.

If you know all that, why not just use an established language you already know and build the API, with the added bonus you aren't in a closed language with a closed system that can disappear at any time?

PLUS you can do literally anything you might need to, without hoping that things like this might get around to implementing that feature in the future (which again makes their tool more advanced, opposite of what they are trying to achieve).

Programming is for programmers, and programmers understand how to build APIs ... it's quite simple.