"APIs" make much of the technical world work. It's a way of letting pieces of code talk to each other when they're otherwise wholly independent codebases.
Does your site process credit cards? It uses a Credit Card Processing API.
Are you teleporting a user in a game engine? You're probably using a Teleport or Player API.
Querying for the stock price of AAPL at 2 am on a Tuesday? Sounds like a Stock API.
API security is essential. API stability is vital, as is the ease of use, reliability, and support. You can't expect users to leverage an API that they can't rely on, especially when they require its features as part of their primary application functions.
However, just as important is proper API documentation. Good docs are like having a good instruction manual with your new office desk. It tells you exactly what tool is for what part, where everything goes, and your result.
Could you build a desk without your instruction manual? Probably. It may take longer, and it may not come out as you like, but you'll get there. You also may have to take stuff apart and put it back together. Trial and error, but you'll get to what you want eventually. Hopefully?
Offering an API without solid documentation is like asking people to poke through your methods and see what happens. They'll be watching the behavior of your functions, seeing what works, what fits their use-case, and how things may work together. Hey, look, that function makes my text bold, and that one logs in a user. Wait, what's that error? What input does it expect? Why did I get error code 400?
I don't know. It wasn't documented.
- Devon
Does your site process credit cards? It uses a Credit Card Processing API.
Are you teleporting a user in a game engine? You're probably using a Teleport or Player API.
Querying for the stock price of AAPL at 2 am on a Tuesday? Sounds like a Stock API.
API security is essential. API stability is vital, as is the ease of use, reliability, and support. You can't expect users to leverage an API that they can't rely on, especially when they require its features as part of their primary application functions.
However, just as important is proper API documentation. Good docs are like having a good instruction manual with your new office desk. It tells you exactly what tool is for what part, where everything goes, and your result.
Could you build a desk without your instruction manual? Probably. It may take longer, and it may not come out as you like, but you'll get there. You also may have to take stuff apart and put it back together. Trial and error, but you'll get to what you want eventually. Hopefully?
Offering an API without solid documentation is like asking people to poke through your methods and see what happens. They'll be watching the behavior of your functions, seeing what works, what fits their use-case, and how things may work together. Hey, look, that function makes my text bold, and that one logs in a user. Wait, what's that error? What input does it expect? Why did I get error code 400?
I don't know. It wasn't documented.
- Devon