APIs All the Way Down

Slightly off topic, but I need to vent: most services are still being built web first, without any kind of API.

From January 1st to send international small packets "it has become obligatory to transmit data, such as the sender's name and address and names of the contents, to the destination postal service in advance converted into an electronic format called Electronic Advance Data (EAD)." By and in itself this is a good thing.

So the Japanese post (JP Post) has put up a website to do this: problem, there is no API... Everything has to be done by clicking and confirming. It's not even possible to register shipments in bulk, they have to be done one by one. About 10 actions per customer per shipment.

I run a (very) small tea business [1], similar to and inspired by Bemmu's Candy Japan [2] after I met him at a Hacker News meetup in Osaka. It's tiny, 100 to 150 shipments per month, but registering a hundred shipments by hand is not something I want to do. One unsatisfactory answer is of course to reach for good old Selenium. And it works, but I hope JP Post will not update its website too often... (unless it is to add an API, of course).

[1] https://tomotcha.com

[2] https://www.candyjapan.com

It looks like everyone has blissfully forgot that API access is often one of the first things to go/get significantly limited once companies reach monopoly velocity (i.e. competition exit velocity).

APIs are awesome, but we need APIs that don't break. I think that happens one of two ways:

- APIs built on scraping (EULAs make this untenable -- companies will just login-wall everything that isn't already)

- Standards-compliant APIs that lock companies into complying to be able to even compete with the others that are standards-compliant (ex. if your API doesn't comply with the SimpleAccountingV1 standard, no one would dare use it)

That's a very good article.

I actually believe in the "API" model (I call it the "Dependency" or "Modular" model).

Dependencies are how small teams do big stuff.

But dependencies are also where truly Jurassic-scale disasters are born.

I think that it is important to exercise moderation in our dependencies, and accept that using them is a major decision.

This is the future of my company’s vision and technical product line (an in-house homegrown ERP that is 30 years old). Our company used to attempt do everything in-house, mostly due to technical (in)expertise and lack of accomplishing what the customer truly wants with the tools available. The previous model I guess would be “database-driven” design, since every new tech stack that was built, whether it was for an e-commerce website or warehouse management system, would require database access first.

Since I joined we’ve been SaaSifying the business model, and we’re going about it with an API first design. The ERP, running legacy code written in Clarion (I would be very surprised if anyone here has heard of it!), would expose its procedures and functions via a .NET layer, which would open up our ERP via an API.

With this approach, we’ve been able to 1) divide up responsibilities extremely clearly within our small team, 2) establish new integrations with relevant places we’ve never been able to before such as Shopify and 3) move existing features that the ERP has to a subscription model such as shipping rates, EDI document transfers, and automatic invoicing.

Needless to say I am very much for API and modular design. It’s better from a team organization perspective, since the responsibilities (and automated testing) is clear. From a non-technical perspective, our sales & support reps can see and understand when features are missing or where the bottlenecks are once we draw out how the API system is architected.

There's a lot of advantages to API-first.

1. You're not bound to one supplier, you can integrate multiple.

2. You don't need to manage the security for a large application, instead, the responsibility is distributed to each API.

3. Scaling becomes a non-issue (unless you abuse the rate-limits/grow too fast).

4. The cost of sysops and development goes waaay down.

The dis-advantages: it might be way more expensive, but at least you'll have shipped! (And of course GDPR/data control might be an issue)

"Shopify is a really smart company. It wouldn’t tie its own hands for no good reason."

Don't underestimate companies ability to do 'only one thing' and 'screw everything else up'.

Shopify has evolved on top of 'a neat thing done well early on' and everything is about scaling that.

I've worked at very successful large tech companies who were actually terrible at doing any other tech than the product they sold.

Why isn't Google doing a Stripe API? Why isn't MS? Why isn't Apple? Why isn't Volkswagen?

They are really separate businesses.

> APIs are an increasingly important piece of how software is built.

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