4 ms·

API Complexity Is a Lie

53 points by bpedro 2y ago

PaulHoule 2y ago
I was looking at monetizing an API about a decade ago and was pretty shocked to see every API management tool out there had zillions of nice to have features but none of them had a facility to attach a payment gateway — the single feature I needed to have a business.
- bpedro 2y ago
  That's a great example of adding features and feeding the complexity instead of offering what customers want.
  - smitty1e 2y ago
    I want to argue: "Well, capitalism contends that someone will show up to offer that product." "Yeah, we'll get right on that," says the cartel.
- dools 2y ago
  How is monetising an API different from any other online business? Surely you still just need a place where people create an account, get their API key, and setup payment details.
  - lazyasciiart 2y ago
    Mostly in deciding and tracking what to actually bill for.
    - dools 2y ago
      I dunno it doesn’t sound like a problem that like, needs a solution. I made an app that is basically an API and I just stuck stripe on it and bill people per second used up to a quota.
- nicman23 2y ago
  you know i was reading the comments and i was thinking that apis are easy then you reminded me about payment processors ...
- whilenot-dev 2y ago
  At least there are licensing gateways nowadays[0]. Now you just need to integrate it with a payment service of choice. [0]: https://keygen.sh/docs/choosing-a-licensing-model/ https://keygen.sh/docs/choosing-a-licensing-model/
interroboink 2y ago
> What is hard isn't the API ... Clearly someone who hasn't gazed into the maw of OAuth :Þ Though I guess the article wouldn't call that an API but "api security" added to the real API. A bit potatoes potatoes from my eyes. ---- Fun reading: https://metacpan.org/dist/LWP-Authen-OAuth2/view/lib/LWP/Authen/OAuth2/Overview.pod#The-Purpose-of-LWP::Authen::OAuth2 https://metacpan.org/dist/LWP-Authen-OAuth2/view/lib/LWP/Aut...
- magicalhippo 2y ago
  I think OAuth is a good example of exactly what the article author is saying. Using OAuth 2.0 isn't very hard at all. You make some straight forward HTTP calls, and potentially show a browser and get a code by listening to a HTTP request depending on flow. Then you take the token and pass it in a regular HTTP header. It's not hard at all. What is hard is the things the article author mentions. The technical language around it if you're new to OAuth. Figuring out how it maps to the libraries like the one you linked to. Figuring out how to register your app with the provider if you haven't done it before. I had to implement my own OAuth 2.0 library, and once I had grokked all the things the author mentions, actually using the OAuth 2.0 endpoints wasn't hard at all.
  - arka2147483647 2y ago
    > I had to implement my own OAuth 2.0 library, and once I had grokked all the things the author mentions, actually using the OAuth 2.0 endpoints wasn't hard at all. Usually the point of an api is to abstract away the nitty gritty details, so you can do something more complex with a few simple calls and particial understanding of the problem domain. Seems like oauth fails at that. For example, nobody expects you to understand filesystem implementations to just open and read a file.
    - akira2501 2y ago
      > you can do something more complex with a few simple calls and particial understanding of the problem domain. Everything is a trade off. You can find plenty of APIs which work this way. They tend to be expensive in one way or another and so they are often limited in use by cost or by time. If that expense is justifiable, perhaps something you don't call often, and which can be idempotent enough to not have to worry about error states that much, then you are lucky and will be happy with the result. > Seems like oauth fails at that. It's in the name. _auth_. Now you have a new trade off. Now between the triangle of secure, cheap, and easy to use we made the most obvious sacrifice of easy to use. > nobody expects you to understand filesystem implementations to just open and read a file. How long of a pathname can you have? Are there any OS special characters you can't use? How many directories deep can you go? Is that actually a file and can EAGAIN be generated? Are interrupts enabled? Did you actually open a directory? What _should_ happen when you try to just read a directory as a file?
whakim 2y ago
The author offers no evidence for the claim that API management and security solutions are needlessly complex in order to create more business for themselves. I think it's much more likely that API management and security software has grown to address the more complex needs of the APIs they serve. It isn't 2010 anymore - handing out plaintext API keys that never expire isn't good enough for many products, and features like RBAC and IAM have become more necessary as more people use APIs to do more stuff. Now let me go remind myself how OAuth works again...
nitwit005 2y ago
> Anyone telling you that working with APIs is hard isn't telling the truth. Having encountered a difficult to use API, I must disagree with the thesis. Or I'm a one of the many people not telling the truth. Who can know for sure?
- bilekas 2y ago
  To me at least there are some nuances, i have worked with bad APIs and had difficulty both trying to see what the provider was trying to achieve and utilise it how I wanted but I don't think I would put that down as being able to work with APIs as hard .
- yen223 2y ago
  Words are squishy. "Hard" and "easy" are words that carry relative meaning. The exact same thing can be correctly described as "hard" or as "easy" if you are comparing against different baselines.
flohofwoe 2y ago
If anybody else is wondering what the heck the blog post is talking about: this is about web dev, which at some point hijacked the term API to mean "custom message protocol".
- einpoklum 2y ago
  I read the whole piece and could not figure out what that guy was talking about. He could have replaced API with some other acronym and it would have sounded mostly the same.
- larsrc 2y ago
  I was wondering wtf he was talking about. Why did they do that?!?
deleted 2y ago
[deleted]
wokwokwok 2y ago
> According to Gartner's 2023 hype cycle for APIs, API security testing was at the top. Sitting at the so-called "peak of inflated expectations," API security companies will most surely enjoy two to five years until the industry matures. Ok. > Today, though, API security testing is navigating Gartner's infamous "trough of disillusionment" showing that it's trying to become mature. Lost me. So in 2003 it was projected they would be around for 2-5 years, but now (2024) they’re in Gartner trough of disillusionment… showing that they’re becoming mature. (?) > There's clearly money to be made in the API security area … In other words, what these companies sell is a painkiller that doesn't fix the security problem but, instead, provides a way to discover and mitigate it. ??? It feels like this is the example of “bad, making things complicated deliberately”, ok, sure, but what does this have to do with the trough of disillusionment and becoming mature? How are those two things relevant or related? Why is it significant that the 2023 / 2024 out looks are so different? How is this “companies making money” related to the trough of disillusionment? I feel like if I just skim the article without trying to actually understand anything it’s saying I get a general sense of what they’re saying but damn I’m struggling with it when I read it closely. :/

53 points by bpedro 2y ago

I was looking at monetizing an API about a decade ago and was pretty shocked to see every API management tool out there had zillions of nice to have features but none of them had a facility to attach a payment gateway — the single feature I needed to have a business.

bpedro 2y ago
That's a great example of adding features and feeding the complexity instead of offering what customers want.
- smitty1e 2y ago
  I want to argue: "Well, capitalism contends that someone will show up to offer that product." "Yeah, we'll get right on that," says the cartel.
dools 2y ago
How is monetising an API different from any other online business? Surely you still just need a place where people create an account, get their API key, and setup payment details.
- lazyasciiart 2y ago
  Mostly in deciding and tracking what to actually bill for.
  - dools 2y ago
    I dunno it doesn’t sound like a problem that like, needs a solution. I made an app that is basically an API and I just stuck stripe on it and bill people per second used up to a quota.
nicman23 2y ago
you know i was reading the comments and i was thinking that apis are easy then you reminded me about payment processors ...
whilenot-dev 2y ago
At least there are licensing gateways nowadays[0]. Now you just need to integrate it with a payment service of choice. [0]: https://keygen.sh/docs/choosing-a-licensing-model/ https://keygen.sh/docs/choosing-a-licensing-model/

interroboink 2y ago

> What is hard isn't the API ... Clearly someone who hasn't gazed into the maw of OAuth :Þ Though I guess the article wouldn't call that an API but "api security" added to the real API. A bit potatoes potatoes from my eyes. ---- Fun reading: https://metacpan.org/dist/LWP-Authen-OAuth2/view/lib/LWP/Authen/OAuth2/Overview.pod#The-Purpose-of-LWP::Authen::OAuth2 https://metacpan.org/dist/LWP-Authen-OAuth2/view/lib/LWP/Aut...

magicalhippo 2y ago
I think OAuth is a good example of exactly what the article author is saying. Using OAuth 2.0 isn't very hard at all. You make some straight forward HTTP calls, and potentially show a browser and get a code by listening to a HTTP request depending on flow. Then you take the token and pass it in a regular HTTP header. It's not hard at all. What is hard is the things the article author mentions. The technical language around it if you're new to OAuth. Figuring out how it maps to the libraries like the one you linked to. Figuring out how to register your app with the provider if you haven't done it before. I had to implement my own OAuth 2.0 library, and once I had grokked all the things the author mentions, actually using the OAuth 2.0 endpoints wasn't hard at all.
- arka2147483647 2y ago
  > I had to implement my own OAuth 2.0 library, and once I had grokked all the things the author mentions, actually using the OAuth 2.0 endpoints wasn't hard at all. Usually the point of an api is to abstract away the nitty gritty details, so you can do something more complex with a few simple calls and particial understanding of the problem domain. Seems like oauth fails at that. For example, nobody expects you to understand filesystem implementations to just open and read a file.
  - akira2501 2y ago
    > you can do something more complex with a few simple calls and particial understanding of the problem domain. Everything is a trade off. You can find plenty of APIs which work this way. They tend to be expensive in one way or another and so they are often limited in use by cost or by time. If that expense is justifiable, perhaps something you don't call often, and which can be idempotent enough to not have to worry about error states that much, then you are lucky and will be happy with the result. > Seems like oauth fails at that. It's in the name. _auth_. Now you have a new trade off. Now between the triangle of secure, cheap, and easy to use we made the most obvious sacrifice of easy to use. > nobody expects you to understand filesystem implementations to just open and read a file. How long of a pathname can you have? Are there any OS special characters you can't use? How many directories deep can you go? Is that actually a file and can EAGAIN be generated? Are interrupts enabled? Did you actually open a directory? What _should_ happen when you try to just read a directory as a file?

whakim 2y ago

The author offers no evidence for the claim that API management and security solutions are needlessly complex in order to create more business for themselves. I think it's much more likely that API management and security software has grown to address the more complex needs of the APIs they serve. It isn't 2010 anymore - handing out plaintext API keys that never expire isn't good enough for many products, and features like RBAC and IAM have become more necessary as more people use APIs to do more stuff. Now let me go remind myself how OAuth works again...

nitwit005 2y ago

> Anyone telling you that working with APIs is hard isn't telling the truth. Having encountered a difficult to use API, I must disagree with the thesis. Or I'm a one of the many people not telling the truth. Who can know for sure?

bilekas 2y ago
To me at least there are some nuances, i have worked with bad APIs and had difficulty both trying to see what the provider was trying to achieve and utilise it how I wanted but I don't think I would put that down as being able to work with APIs as hard .
yen223 2y ago
Words are squishy. "Hard" and "easy" are words that carry relative meaning. The exact same thing can be correctly described as "hard" or as "easy" if you are comparing against different baselines.

flohofwoe 2y ago

If anybody else is wondering what the heck the blog post is talking about: this is about web dev, which at some point hijacked the term API to mean "custom message protocol".

einpoklum 2y ago
I read the whole piece and could not figure out what that guy was talking about. He could have replaced API with some other acronym and it would have sounded mostly the same.
larsrc 2y ago
I was wondering wtf he was talking about. Why did they do that?!?

deleted 2y ago

[deleted]

wokwokwok 2y ago

> According to Gartner's 2023 hype cycle for APIs, API security testing was at the top. Sitting at the so-called "peak of inflated expectations," API security companies will most surely enjoy two to five years until the industry matures. Ok. > Today, though, API security testing is navigating Gartner's infamous "trough of disillusionment" showing that it's trying to become mature. Lost me. So in 2003 it was projected they would be around for 2-5 years, but now (2024) they’re in Gartner trough of disillusionment… showing that they’re becoming mature. (?) > There's clearly money to be made in the API security area … In other words, what these companies sell is a painkiller that doesn't fix the security problem but, instead, provides a way to discover and mitigate it. ??? It feels like this is the example of “bad, making things complicated deliberately”, ok, sure, but what does this have to do with the trough of disillusionment and becoming mature? How are those two things relevant or related? Why is it significant that the 2023 / 2024 out looks are so different? How is this “companies making money” related to the trough of disillusionment? I feel like if I just skim the article without trying to actually understand anything it’s saying I get a general sense of what they’re saying but damn I’m struggling with it when I read it closely. :/