I dont get how you learn to use API's!!!
Posted by NoTap8152@reddit | learnprogramming | View on Reddit | 61 comments
I've been learning to code full stack for about 6 months now, and I'm trying to learn how to use API's, I chose to start with stripe cause I heard it was the easiest and most straight forward cause I originally was going to try and start with airtable but that was definitely a mistake. The issue I ran into was that the "docs" if you can even call them that are so confusing and the code just doesn't work with my stack, cause my stack is react, typescript, nextjs and I chose the setup for nextjs and it was all code in js so in my mind I was thinking I could just easily fix the type issues and that was going to be it but it didn't work like that, there were no type issues it was other errors that there docs had no help with. So how am I supposed to fix this when with API's its not like other problems with crud where its usually just giving the issue to you, like every website I look at to setup stripe its completely different code across all those websites. So what I'm trying to ask is how do you learn API's cause googling has done nothing for me, and I've used AI to try to help me and gotten nowhere cause I've heard that somehow stripe is one of the easiest API's for beginners to work with. I've also heard that all API's have the same structure so getting over that initial learning hurdle is the hardest but how true is that?
No_Community_4342@reddit
API docs can definitely feel overwhelming at first especially when examples don’t match your stack. What helped me was focusing on one simple endpoint, testing it step-by-step, and gradually building from there instead of trying to understand everything at once. Also, recording your process with something like bandicam's can actually help a lot you can review where things break and catch small issues you might miss in real time.
Content_Zombie_5953@reddit
Stripe is well documented but it's not simple. It has webhooks, checkout sessions, subscription lifecycle, idempotency keys. That's not "beginner API" territory. People who say it's easy already understood APIs before they touched Stripe. Start smaller. Pick an API that does one thing with a single GET request. No auth, no webhooks, no setup. Call it from your Next.js app, see the JSON come back, render it. That's the learning moment. Once you've done that a few times with different APIs, Stripe will make a lot more sense because you'll understand the pattern: make a request, get a response, handle the data. If you want a list of APIs filtered by auth type so you can start with no-auth ones, patchbay.cc/guides/no-auth-apis has a bunch sorted by category. Good for just picking one and experimenting.
Cautious_Elevator456@reddit
Try something simpler first: test the endpoint in Postman or curl, then implement it in a backend route (like a Next.js API route), and only after that connect your React UI. Most APIs follow the same pattern: auth, request, response, so once it clicks the others start feeling similar.
If you ever end up dealing with multiple APIs https://www.getkonvex.com can make that layer easier to manage.
Apprehensive_Rub_221@reddit
I honestly never understood how to use APIs until I was forced to build my own. For a long time, the concept just didn't click.
The turning point was a project where I was using Local LLMs to interact with an MPC and the Obsidian API. In the process of trying to get those systems to talk to each other, my knowledge of how APIs actually function—and how they interact—just exploded.
When I built my first API, it sucked. But that was the most important part of the process. Having a bad initial build made me realize exactly what an API is for and, more importantly, what makes an API "suck" from a developer's perspective. As I iterated and improved it, my understanding deepened even further.
It's hard to explain the full technical shift in a single text, but that’s the high-level overview: I didn't learn APIs by reading documentation; I learned them by building a bridge between my own tools.
Ronak_Builds@reddit
I struggled with APIs a lot too.
Docs make sense only after you try breaking things a few times — you’re not alone.
ReefNixon@reddit
Respectfully, who tf told you Stripe's API was the "easiest and most straight forward"? They lied to you. Payment processing is not trivial, and is a terrible way to learn about APIs from a base of nothing.
Go here: https://free-apis.github.io/#/browse - pick one that has no auth, make a page for each GET endpoint the API has, and display data that you have fetched from the API. Then move on to one with API key auth and do the same, then move on to one that has OAuth and do it again.
Once you've done that go to https://restful-api.dev/ - try creating a record with a POST method, take the ID from the response and GET it. Once you can GET it, try to PATCH and PUT it, then ultimately DELETE it. You can practice this loop.
REST API docs will make much more sense to you at this point when you actually understand auth and what the verbs are for. This knowledge is directly translatable to GraphQL queries and mutations, there are many guides, this is a decent one to see the difference between RESTful GET requests and GraphQL queries https://docs.github.com/en/graphql/guides/migrating-from-rest-to-graphql
APIs are typically intuitive because we have common conventions, but you have to actually understand those conventions first. If it puts your mind at ease, well established APIs (like Stripe) are rarely a point of friction when you actually know what you're doing, but you're trying to build a house starting at the roof tiles.
Pyromancer777@reddit
Wish I could upvote this more than once
kay-jay-dubya@reddit
After trying to absorb that stream of consciousness (and failing to do so), I did happen to see the question here:
The short answer is "practice, practice, practice", but that's probably not as helpful as you want it to be.
Have never used this Stripe API, but I had a quick look at the documentation. Honestly, I do not understand your point about an API being "easier" or "harder" than another - because REST APIs are all kinda the sameish (GET requests, at least) - but my only thought after having looked at it is: "why would you want to learn APIs with something as dull as a payment provider?"
How about trying Space Traders? https://spacetraders.io/ It's an game you play online through API calls.
NoTap8152@reddit (OP)
well I was looking into stripe cause I thought it was going to be basic and straight forward since a lot of websites use stripe and a payment system seems necessary for a real project.
and for API's being easier or harder I meant like i thought they were all basically the same, but with there own slight differences, cause with airtable for example they got rid of the API key and now its oauth, so that adds another step of learning and also you need to read the data and display so its different from stripe where its just POST.
Yoduh99@reddit
But you're not trying to build a "real project" right now, you're just trying to learn, right? Payment processing is something that needs to be super secure, safe and be able to handle complex use cases for large enterprise applications (e.g. Amazon, Lyft, Airbnb...), so inherently won't be "simple". Simple and easy to learn APIs are going to be ones that are not practical like a Star Wars API. Practice with a free silly API like that, then move on to building your own with node + express.js, again keeping it simple, start with a single GET endpoint, then add POST, PUT, DELETE, and ta-da you have a RESTful API that you understand.
Pyromancer777@reddit
^ this is good advice. Had to do a few projects around the Pokemon API. It may not be practical, but it is well documented and has object structures complex enough to get familiar with pretty much any type of data retrieval
materialkoolo@reddit
Stripe is far from basic. Start with something smaller and easy to work with like the Cat API, Github API, or Wikipedia API.
Use something like Postman to make test queries so you can see what each endpoints return to get a feel for the data structure, then build a front-end to display that data.
AdministrationWaste7@reddit
API is just a generic term for public facing communication protocols that lets you access functions of a system.
for example when running a program in a command line that asks for input is an API.
often times when people throw around the term "API" they usually mean web based communication protocols such as http.
you mentioned Stripe which offers developers access to a suite of Restful APIs. "Rest" is a term that describes a *style* of creating/implementing http apis.
so before looking into any specific platform i suggest you start with the basics.
here are some freebies commonly recommended by people.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Overview
https://restfulapi.net/rest-api-design-tutorial-with-example/
NoTap8152@reddit (OP)
Im not really looking to build my own API as i feel that would be a bigger hassle then trying to use a popular one from stripe, notion, airtable, trello, slack or so on.
I will definitely look into the HTTP and REST. And I need to get comfortable with postman I have it downloaded but haven't used it ever.
also I'm not sure what your using but I've heard that with the app router that you should use server actions for API's instead of route handlers and if you notice any difference cause the API would work with both I'm pretty sure but I don't know what's the proper way, or if it would be smart to just learn route handlers anyways to learn more in depth about that area.
AdministrationWaste7@reddit
building your own api gives you an understanding of how web based APIs function.
as someone who doesnt even understand http i highly suggest making your own so you can start small and raise the complexity at your own pace.
im going to be honest. spend time understanding stuff on your own before taking people's opinions on the internet to heart.
you are trying to run before you even know how to walk.
NoTap8152@reddit (OP)
I asked about there opinions on the 2 options since i am probably the least experienced person in these comments. And they probably know better practices than I do
and I thought like just learning how to use a "popular" API would've been better than trying to build my own from scratch, cause in my head it sounds like "you dont need to build a car yourself to be able to drive".
Pyromancer777@reddit
When I took courses, pretty much right after they taught us how to read JSON, query SQL/noSQL, and learn how to call an API, they had us create our own. Everything clicked pretty much instantly after I got to code one myself.
You may still be in the "learn how to call an API" stage, but definitely take a crack at any free resources that teaches you how to build one. It will give you insight into the whole data handshake that takes place between the DB and the UI
sixtyhurtz@reddit
It's actually a lot easier to use a framework if you've made your own basic version of it first. I wrote a simple SPA in vanilla JS before ever trying React. I write a simple MVC application server in PHP before ever using Laravel. Neither of them were good, but I learned a lot about how the popular systems work.
FishBobinski@reddit
You say that you want to learn full stack. You need to know how to write your own APIs to do this. That's how your frontend will talk to your backend.
You can build your own API that simply returns the system time, and it will help you understand the Hows of APIs why easier than using some pre built free api.
PineappleHairy4325@reddit
You don't know enough to be focusing on beet practices.
Internal_Outcome_182@reddit
Stop being so opiniated, guy is trying to help you. No one is expecting you to build a car, build simple hello world, slap some swagger on it and that's it. Understand how to call it using in build swagger, later add some db, 4 methods/sometimes 7 if u want to go deeper. You approeach is wrong. If you are going to be this way, stop.
AdministrationWaste7@reddit
i dont really understand how the analogy fits since programming is about building things.
JosephHughes@reddit
You already are. You just don’t know it. Your nextjs app is doing file system endpoint routing. I’m on my phone so some of this might be not 100% correct but your nextjs app will expose endpoints like
/homethat returnshome.jsxthat’s a http GET request to your nextjs api.Kirides@reddit
God I wish "public facing apis" would provide a technical guide to their APIs.
We do business to business comms and our "APIs" we work day to day, are implemented based on "someone told me this XML field needs this value here" and things like open API specs and XSDs are completely worthless, as our "providers" have a single, god-schema with all optional fields and no definition of any "required" properties at all, as it's "per customer" what is a required field and what not.
Our last 9 big industry APIs we had to implement all went like this.
Every single API I worked with on my free time,like twitch, YouTube, league of legends, GitHub, docker,.... All had proper followable technical documentation.
B2B business the way we do is BS.
Don't call something an API/Interface if you DONT EVEN PROVIDE INPUT OR OUTPUT DOCUMENTATION.
az987654@reddit
The large majority of them do. It sounds like you've glossed over some of the basics of programming and are not understanding the documentation you're reading.
jlamamama@reddit
No way, some B2B apis are not only bad but not documented well or at all. Optional fields, requiring specific hard coded strings, not providing a list of choices or an explanation of what each choice does. Some really bad ones are from Chinese companies, which are documented in Chinese or run through google translator. I’ve had to reverse engineer entire APIs before.
Kirides@reddit
Oh no, the sort of "documentation" we get from our "providers" is "here is an XML file with some example data. Send us the same." Constantly getting validation errors from all sorts of WAFs and in-between ETL processing limits, like, field values may not exceed 50 characters, and other non documented garbage.
Literally.
Our providers don't hand out any PDFs, (online) documentation or other helpful guidelines. It's 99% of the time some random example file, be it XML, a dialect of CSV (I say dialect, because some of those "CSV" files do not support Quoted field values, or require all field values to be quoted, don't support newlines, only support latin-1 encoding, and other garbage.
happy_user_1000@reddit
From your problem description it sounds like your issue is that you don't know how to break down the problem into smaller tasks, and how to "translate" each of those tasks to the right API call (and from there find the right API endpoint and call it with the right parameters.)
Stripe is a pretty established software at this point, so if you cannot work out their API, you will most likely have difficulty using other APIs as well.
So:
Rokett@reddit
when Ai wasn't around, I used to search github repos that used that particular API. So, I could see and read how they used it. Worked like charm but today, that is no longer needed, maybe some edge cases here and there.
mobsterer@reddit
become more structured, start with any text you write requesting help.
tontoandbandit@reddit
this comment is hilarious 😂
jankysysadmin@reddit
If this is your first time learning APIs, you're really trying to learn two things simultaneously: * how APIs work (general knowledge) * how the Stripe API works (domain knowledge)
It's probably best to pick something you're probably already familiar with, such as GitHub, and learn that API first so you can focus on fundamental concepts. My recommendation would be to start with GET requests that don't require authentication, such as getting a list of issues in the React repo. After that you can learn how auth works and make a request using an API key.
NoTap8152@reddit (OP)
for auth I've been using better auth and its been pretty smooth so far but I've had quite a bit of experience with it.
Its just I don't see how its going to be easier with githubs API instead, I feel like its probably going to be similar issues with the stripe API.
tooObviously@reddit
you know how to implement better auth but don’t understand what an api is 🙂↕️
scoobjixon@reddit
i would literally start by trying to use the dog api to display some dogs from a frontend API call: https://dog.ceo/dog-api/ - security sensitive things like stripe are not a good option for learning the basics of making an api call
AlternativePear4617@reddit
WTF. You heard wrong!
You should try with easier apis like https://fakeapi.net/ (I did a quick search for an easey one) for example or something like a weather api or something like that.
Jazzlike-Compote4463@reddit
First get to know the basic HTTP request / response cycle
This is the basic cycle that handles most Create / Read / Update / Delete (CRUD) actions that happen on the web (get me this webpage (Read), make a new comment (Create), edit my comment (Update) and delete my comment (Delete)
Now, are visiting a site where people can compare the price of insurance from different providers, this flow would work like this
APIs are just a way for a machine to talk to other machines, Stripe is "simple" because it does a lot of step 5 for you and is well documented, the actual use case is pretty complex.
TheDoctorColt@reddit
APIs can seem daunting at first, but starting with simple ones like a weather API can make the process fun and give you confidence to tackle more complex ones later on.
oscurochu@reddit
you can understand api's by writing your own API
oscurochu@reddit
Imagine you are hungry and find a tiny, sliding window in a wall of infinite obsidian. This window is the API. You can't see who is inside, and you don't know how they make the food. You only know the rules posted on a sign next to the window (the Documentation).
1. The Endpoint (/order/sandwich) The sign says if you want a sandwich, you must go to the blue window. If you want a drink, go to the red window. If you try to order a sandwich at the red window, the window just slams shut (404 Not Found).
2. Authentication (The API Key) Before you even speak, you must hold up a very specific, rare collectible trading card to the glass. If the card is a common duplicate or a fake, a voice yells "I don't know you!" and the window stays locked (401 Unauthorized).
3. The Headers (The "Ham Hat" Rule) The documentation says that all customers must be wearing a hat made of sliced ham. It doesn't help the deli make the sandwich, and it feels ridiculous to you, but if you aren't wearing the ham hat, the worker refuses to acknowledge your existence (400 Bad Request).
4. The Request Body (The JSON Payload) You must slide a note through the crack. The note cannot just say "I want turkey." It must be a perfectly formatted list: Protein: Turkey Bread: Rye Mustard_Atoms: 4,000,000 If you accidentally write "Bread: Toast" but they only accept "Rye," the worker throws a pickle at your head (422 Unprocessable Entity).
5. The Response (The Data) If you follow every single absurd rule perfectly, a briefcase is pushed through the window. You open it to find a single, frozen grape and a piece of paper with a code on it. That code is your "sandwich." You then have to take that code to a different window to actually get the bread.
magick_bandit@reddit
Do you understand what a method is?
Conceptually that’s all an API is.
joshua_dyson@reddit
This is normal. APIs don’t really “click” until you stop treating them like something to study and start treating them like something to poke in production.
In practice, learning APIs is:
Once you’ve wired a few real API calls into code and dealt with auth errors, bad responses, retries, and rate limits, the docs stop feeling abstract. You’re no longer learning an API, you’re learning patterns, and those transfer everywhere.
Every experienced engineer has gone through this phase. It’s not a you problem.
neo101b@reddit
You would need to learn about how the API is structured, usually the website hosting the API has a technical manual on it. So you can learn the commands it responds too, every API might be different.
friendly-manspider@reddit
There’s some fun stuff you can try if you’re just learning how to use web APIs too. I think there used to be one that would give you info/stats about Pokémon. So you could build a toy website that allows you to search by name and return the stats about that Pokemon. I would look up a topic of whatever you’re into and use that to start with. Always better if you can combine a topic that you genuinely enjoy. Best of luck!
96dpi@reddit
That was a bear to read.
Usually it's just JSON objects. Are you familiar with JSON? You make an asynchronous request to the API, then it return the JSON object.
NoTap8152@reddit (OP)
I haven't used much of JSON cause you use it mostly for fetching API's right? Cause I also just learned about dynamic backends that you make a field with json/jsonb so that's new to me also.
so that's what I'm trying to work on. I've also ran into the server action vs the route handler and heard that with the app router to use server action instead, but I don't know if I should just start with the route handlers to get comfortable with that first instead of jumping ahead.
Prestigious_Towel_18@reddit
It seems you are getting a little lost in the weeds here, and some of it might be because of Next J's which if you don't have a decent knowledge of APIs will make understanding harder.
Server actions are just like any other API endpoint, they are actually a POST request endpoint under the hood, so they are an API route so to speak.
That said, server actions are meant to be used when you want to mutate data on your application.
If you are setting up your next JS application to be your backend API, then you would use next route handlers for get requests (getting data from the weather API for example), and server actions when you want to modify/mutate something.
I'd highly suggest for you to try to understand the basics of http and apis in general, as next has quite a few abstractions that will only make it harder to understand down the line.
HirsuteHacker@reddit
JSON is used everywhere for tons of different things. If you want some structured data in a structure that basically every language understands/has tools to handle, is relatively human-readable, and that mirrors native array/object structures (so is easy to serialise and send over a network), then you pick JSON.
Or XML, but nobody really uses XML these days for this sort of thing.
Teleconferences@reddit
I think there’s a disconnect here. You said you choose the setup for NextJS and I think that’s where the problems live. It sounds like what you did (which isn’t actually wrong by the way) is download the Stripe SDK for Next JS. This is (likely, I haven’t used it) a bunch of prewritten code from Stripe which aims to make your life easier. No guarantees it will, but that’s the gist.
What everyone else seems to be mentioning with HTTP and REST is correct, but it’s a bit of a different thing. See, what I’m guessing is going on is that Stripe has a public facing REST API. This, functionally means they have a bunch of endpoints (aka URLs) you can send a request to and get data back. Using that API is where that HTTP and REST stuff comes into play.
The SDK is basically a wrapper around the API. It has a bunch of (ideally) easier to use code that, under the hood, makes requests to the API itself. The SDK is entirely optional, but its goal is to make your life easier. If you want to do a more barebones implementation, try removing the SDK and sticking with just the REST API
MihaelK@reddit
Learn to use paragraph and better formatting. It's hard to even understand what you're trying to say.
If you are a complete beginner, I wouldn't start with Stripe. I would start with something very simple as JSONPlaceholder, or some public weather api to get more familiar with the flow of using API keys, making requests back and forth, and using that data to do something.
Don't copy paste something that you don't understand.
NoTap8152@reddit (OP)
My bad on the formatting I need to get used to that with reddit.
one of the first youtube tutorial projects I did for learning was the weather api but I feel like it didnt teach me much probably cause youtube tutorials are just passive learning.
Also wouldnt the weather api be like basically the same process as the stripe api? Cause like I said I heard that api's structure is basically the same across every api.
HirsuteHacker@reddit
Youtube videos and tutorials are great, but you can't fully rely on them. If you're using them while learning you need to be stopping the videos every now and then while you experiment and try things to see what changes. Use tutorial videos more as guidelines rather than strict things to follow precisely.
Every API is different, but the basics of these web APIs is make request -> get response. But every API is going to require different things in the requests, and you're going to have to do different things to properly handle responses in any useful way.
Odd-Fall-1865@reddit
If you are learning full stack and interested in API, just start with simple API yourself
A simple server that host API that you can call to get some message, well hello world or something
And make your React code to call this API through fetch()
You see the hello world rendered on your page, congrats, you learned API
The rest is, as someone noted, domain knowledge. Your English comprehension will be more important for this
Stripe has a pretty good documentation, so that is definitely a good start
MiAnClGr@reddit
I would just slow down, create some basic endpoints that return and update data. Just start with and endpoint that allows you to GET and POST a single bit it data likes string.
HippieInDisguise2_0@reddit
API is a term that means many things in tech. In your case I'm guessing you're talking about web APIs.
It should not be very difficult to get them to work, the key thing is probably start with postman and try to get the structure of the request and response right in your head and then work on implementation.
A request is formatted in a specific way and can require certain headers to function. It may also expect a specific format for a body, usually this will be JSON and it could have some additional requirements in that JSON.
This is a relatively basic programming task and you should try to reach deeper to the underlying protocols that make this work to get a better understanding.
To be completely honest you come off as someone who does not understand what an API is or how it should be used. Without this understanding you will be wasting your time.
BizAlly@reddit
You’re not alone, this is exactly how APIs feel at the start. Docs are often confusing, examples don’t match your stack, and every tutorial shows different code, which makes it worse.
APIs aren’t learned by copying setup code. Once you understand that it’s just sending a request and reading a response, things slowly click. Stripe is considered easy, but it still feels hard for beginners because of auth, server/client separation, and framework quirks.
The first API is the hardest. After you fight through one, the rest start to feel familiar. Keep going this struggle is actually a good sign.
silvses@reddit
Check out space traders 'api game', you build everything up from just the API calls they provide you. I found it to be a good playground for experimenting how it works.
ThisisnotaTesT10@reddit
I agree it feels like a lot “documentation” that orgs give on how their APIs work sucks. I usually just find the endpoints and try querying them with Postman or something to get a better idea of what they return
NoTap8152@reddit (OP)
How has postman been working for you? I have it downloaded but haven't used it at all since I just got into the API part of learning to code, cause initially I expected these billion dollar companies to have good docs but its far from that and its been nothing but struggle.
AdministrationWaste7@reddit
the documentation on stripe is very good. they are just aimed at an audience that is expected to know what they are doing.
they can be daunting for newbies because they are "enterprise" level web APIs.
mxldevs@reddit
Forget about APIs
Learn how HTTP works.
Start by hitting F12 in a browser to open dev tools and go to the network inspector and start browsing the Internet.
Look at the request, payload, and response tabs
Then go and find out how to programmatically send requests and handle responses.
The first step isn't to read API documentation, it's to figure out how to communicate with servers.