because I see a lot of people approaching automation from this attitude of "software/sites should have APIs so that users can write software to automate it!"
and while that's not wrong, exactly, it's also not the attitude I think makes the most sense, you know?

We do not ask for access. We don't need to get permission to be able to automate our tasks.

There is always API 0: acting like a human/browser/user.

The first API is "fuck you I'm doing it anyway". Any additional API the program provides is merely a helpful shortcut

like, if your API doesn't provide me a follow_user() call, but the user can follow anyone by clicking one link?

Your lack of a follow_user() call is not going to stop me. I'm just going to click the link, automatically.
Having an API 1.0 doesn't mean API 0 goes away.

my point is that every program, every website, DOES expose an API, you just need to know how to best use that API.

That API being "the access they provide for humans"

I think of this as a short term vs long term thinking sort of problem. Like, a lot of programmers are stuck in the "should" part of thinking about programs and sites.

Yes, the program SHOULD be open source, so you can just fix the UI. Yes, the website SHOULD have an extensive API so you can easily automate it.

I agree with all that!

but... it doesn't.

by all means, try to switch to open source alternatives or get them to fix it or add an API.

But at the end of the day that's asking "the enemy" to do something for you, and they are under no obligation to listen to you.

(They may not even exist anymore, given that a lot of the times when I've used this sort of Adversarial Automation it's been focused on software from decades ago)

But the fact is, often times people have jobs where they aren't self-employed and have to work for other people, and those other people can be like "you need to use FooBaz 2007 for this job".

Would it be easier to automate if you were using OpenBaz? Certainly! But your boss can still tell you "no, we're not switching to OpenBaz, we need to use FooBaz 2007"

well, at the time the only way you could make books for apple devices was to use the book creation program, which was basically a word processor. It was focused around the idea that you would create your books inside it.

Well, we already had our books created.

We didn't want to have someone retype them.

We could import them as plain text (or DOC, I think?) and that'd get the actual text content of our books with some minor formatting, but we had very interactive and multimedia books. Tons of images, cross links, quizzes, and so on. Pretty much all things that the apple book format supported, but didn't support importing.

Should Apple have provided better docs and interfaces and APIs?
Yes, of course!
We asked for them.

But at the end of they day, they may not. And we need to publish this stuff soon, not in several years when Apple decides it might be a good idea for the next revision

My overall point is something like:

By all means, use APIs and official channels and built-in scripting support if you can.

But remember those are only shortcuts to automation. You can always ignore them and off-road.

My silliest example of this sort of thing:

I was automatically taking screenshots of a DS game in an emulator. my program would load a savestate, jam some new data into the DS's RAM, hit a button, then screenshot it. But the emulator was showing a "SAVE STATE LOADED!" text overlay over the game's window, no matter what option I set.

I open the EXE in a hex editor. Find the string "SAVE STATE LOADED!", and change the first character to a NUL.

Now the emulator is still showing the message, but since it's zero characters long, it's invisible. Problem solved.