Quality Bits

API Testing with Callum Akehurst-Ryan

• Season 2 • Episode 2

Share episode

APIs - what are they? What should we keep in mind when testing an API? What are the benefits of API testing over UI testing?

This episode's guest is Callum Akehurtst-Ryan, a principal test engineer at Chetwood Finance, who is on a mission to educate more testers (and not only) about APIs and their testing. Not only you're going to learn what APIs are, how to test them, or where to start, but also hear Lina and Callum discuss the terms technical vs. non-technical. If API testing sounds like a challenge, then this episode will help you by simplifying sometimes overcomplicated terms and leaving you inspired to learn more.

Find Callum on:

Mentions and resources:

If you liked this episode and would like to dig deeper into a type of API testing - contract testing that Callum mentions, check out this past episode of Quality Bits:
Contract Testing with Lewis Prescott
https://www.buzzsprout.com/2037134/12402778

Follow Quality Bits host Lina Zubyte on:

Follow Quality Bits on your favorite listening platform and Twitter: https://twitter.com/qualitybitstech to stay updated with future content.

If you like this podcast and would like to support its making, feel free to buy me a coffee: https://www.buymeacoffee.com/linazubyte

Thank you for listening! ✨

Lina Zubyte (00:06):
Hi everyone! Welcome to Quality Bits - a podcast about building high quality products and teams. I'm your host, Lina Zubyte. Recently I saw this article about APIs: what they are, how to test them, and I really liked it. I thought that more people should write in such a clear way and explain concepts that for some may sound a little bit scary. That article was written by Callum Akehurst-Ryan, whom I'm talking to today. This episode is mostly dedicated for beginners. So we talk what an API is, how would you test it, some common bugs that you could find with it, but we also go into a few more stories that may be interesting, even if you are a seasoned user of APIs. Enjoy this conversation.

(01:09):
Hello, welcome to Quality Bits. Could you please shortly introduce yourself?

Callum Akehurst-Ryan (01:15):
Hi, I am Callum Akehurst-Ryan, principal test engineer at Chetwood Finance, a known advocate for exploratory testing and a veteran of the testing community for the last 16 years. So yes, hello.

Lina Zubyte (01:32):
Lovely to meet you. So it's been 16 years. What are the things that are highlights or milestones from your career to you?

Callum Akehurst-Ryan (01:42):
Oh wow. I've worked in a lot of things. So some of the big ones: I was able to, in the early days of civil partnerships, get a finance company to change their wedding calculator to include civil partnerships as well. So yay for inclusion. I really appreciated that. I've really enjoyed being able to train people and give talks across places like the Ministry of Testing. I've really enjoyed a lot of those as well. And oh, I really enjoyed working as a consultant where I got to do some proper pure exploratory testing where I was given a product that had no documentation and I got to go through the stack and try and learn it and share that to people. That was awesome.

Lina Zubyte (02:31):
Awesome. Sounds great. So in this episode I'd like us to talk about API testing, but to begin with in testing community especially there is this misconception: technical versus non-technical, that some people are more technical. What are your thoughts about the terms a technical person and non-technical person? Sometimes I'm like, we're all technical, are we though? What would you say?

Callum Akehurst-Ryan (02:57):
Yeah, it's interesting because lots of different people put the idea of what is technical in different buckets. So some people say that you are only technical if you're writing code, but there are all sorts of technical skills. Any testing skill is a technical skill. So the ability to analyze things is a technical skill. The ability to come up with test cases is a technical skill. The ability to ask questions is a technical skill in testing, but it's sometimes used as a bit of a way of trying to almost gate keep people out of like, oh, you are not a good enough tester because you only do these things. But it's just that people have different experiences, people have different opportunities to do different things. Not everybody gets the opportunity to sort of work on greenfield development and look at full stack testing, but there's lots of different technical skills that people have. Even people who are manual testers using a UI can be a technical skill using SQL or databases - a technical skill. So people sometimes scare themselves a bit and say, oh, I'm not technical, I couldn't do things. But they've already learned a lot of technical skills and they are technical. So yeah, for me it's this weird place and it's again, it's like the testing checking or manual testing versus exploratory testing. It's labeling things where everybody has different interpretations of those labels and it's just a way of creating little "us" groups and "them" groups or trying to make yourself look good sometimes. So technical versus non-technical, depending on who you ask, you'll get different answer.

Lina Zubyte (04:48):
Saying that it's sort of gatekeeping is extremely powerful because then we're siloing, we're not as collaborative. We put people into boxes and it's not nice to be put into a certain box. One memory pops into my head is when I worked at a project and we were just me and my PO in the room and a lot of other team's people came to discuss the API design. Everyone was gone except for us two, of course this is as well, I was a QA, she was a PO, we both were women as well. They started demanding to speak to developers. They were like, where is this? Where is that? And we're like, what do you want to talk to them about? And they were like the API specifications and we're like, it's fine, we can go. And we went and we spoke to them and they were really surprised that we could understand what they are talking about. But this technical, non-technical is still so out there and APIs may seem very scary, right? It's like what API, there's an abbreviation already. So that's scary in itself. So how would you describe an API to someone who doesn't know about it, to whom it does sound scary? What is an API?

Callum Akehurst-Ryan (06:09):
So an API is a transporting of information. You've got two services and you want 'em to be able to talk to each other or the piece of software or the code that basically talks from one to another is an API. It's just an interface basically. That one thing can say, here's some information or can I get this information from the other? We have different types. Of course. The most predominant one that we deal with in this day and age is something called a restful API. Most things use it. If you've used the internet at all, you're probably using a restful API. And all that is is it's basically a way for a webpage to say, Hey, backend, hey database, can you just go get me that information and it will make a request and it'll bring it back across there as well. So all it is is just that conversation between two different pieces of software. So a pretty simple thing.

Lina Zubyte (07:09):
Yeah, actually thinking about restful APIs, it's mainly four different requests that we can make. We can put post, we can get and we can delete.

Callum Akehurst-Ryan (07:18):
Yeah, the acronym I use is CRUD. CRUD for create, read, update or delete.

Lina Zubyte (07:25):
Yeah, CRUD is used in quite many places for anyone listening to understand that it's not something very, very scary or mysterious. It's quite simple. So sometimes thinking about APIs, I think that there is some kind of, not stereotype but habit that usually testers get into UI testing first and API testing is something that may be some dip their toes a little bit into. But don't you think it's a little bit maybe a better step for us to start in API testing and to learn more about them rather than go into a very complicated front end? Because front end can change so much and they have so many complexities, right?

Callum Akehurst-Ryan (08:07):
Yeah, I've worked in a lot of organizations where the front end changes the most and changes to the front end are quite easy to make. So it's a very chaotic and thing that can change quite often. So if you are writing, especially if you're starting an automation, but if you're doing manual testing, your front end can be very changeable all the time. But also it's usually the thing that's developed to last. So it's something that you don't get hands on with for quite some time. Breaking down to the next layer down your APIs, there's usually one - less of them. They've got more fixed things that they can do, they're easier to test. It turns out that they change less or when they do change, it's usually just adding bits of data into them and so on. So because of that, yeah, you're quite right. It's probably better for people to start at that layer of thinking, but we're told as testers quite often to stick to the business side of things, especially as manual testers.

(09:11):
We are told like, oh, you won't understand this, you can't understand this. And people internalize it and they get scared of things because told, oh, this is development, this is technical, you won't understand it, or you are not the right sort of person to understand this. So sometimes we can get a bit worried about things. And on top of that, a lot of training to do with API and API testing can come across as quite technical because it might be related to Cypress or automation or software development in test. And so people are looking for training in how to test APIs, but they're looking at the wrong type of testing for them. If you're a manual tester or an exploratory tester focusing on behaviors, you want to know what is an API, what does it do, why does it do it?

(10:03):
And then how can I play with it, how can I get it working? But a lot of the training might be, alright, fire up Cypress, here's your framework. I hope you know how to use JavaScript, look at the code, pull the repo. And that's a lot of learning all at once. You're not just learning APIs, you are learning automation and frameworks and code all at once. So the way that we teach people testing and the way that we teach them these sort of different layers of the stack can be a bit overwhelming for people, especially if we're trying to teach them sneakily, teach them automation instead of just the testing side of what these APIs are. In fact, there's some really useful training that we'll probably talk about it a lot later, but there's a tool called Postman, which is a really good tool for testing different types of API. And I've seen them at a lot of conferences where they're actually teaching people how to use Postman for API testing. And that's really powerful because it's teaching how to actually interact with an API rather than an automation framework or something.

Lina Zubyte (11:11):
I think in general, this question, that's as long as the humanity is here, is still relevant about education: how to make education somehow accessible to everyone and not to overwhelm people. And in tech maybe sometimes we tend to overcomplicate things, we tend to use vocabulary that's not really clear and we hide behind the tools. So we're like, Ooh, use this tool and then you'll know everything.

Callum Akehurst-Ryan (11:40):
Also, as we can see at the moment, the market is terrible for finding new jobs, for finding jobs in tech especially. And we've seen there's been a lot of layoffs from some of the big tech corporations. So people are understandably maybe a bit afraid of losing jobs and trying to safeguard the knowledge that they have to make them seems indispensable. So a lot of times in those situations and people who with those technical skills will try and lift them up and make themselves look very overly important and like they know a lot of things but they might not train other people on them. So we see that. Not always in the testing community for sure. I think the testing community more than any other software development community is a lot more open to sharing information, but you do sometimes see it and it comes from a place of people feeling a bit worried or scared that they're going to lose a role or not be able to find a job.

(12:44):
And that's understandable. But it does mean that sometimes we end up with people not helping each other, training each other in these things or showing that they're not scary or saying, Hey, I know this tool, it's the only tool. I know this technique. It's the only technique. If you don't know it, you are no good at testing. And that again, makes some people a bit more nervous. I'm very lucky I come from the testing bubble on LinkedIn and Twitter and all those sorts of things where I talk and exchange information with people and you can get into a bit of a bubble of thinking that everybody talks about these sorts of things and everybody's sharing information and everybody's going to conferences and everybody knows everything and people know each other and they can reach out. But it's not always true. And there's a lot of organizations and there's a lot of testers out there who won't listen to this podcast who might not be on LinkedIn talking to people, but they might Google and they might say "APIs" one day and if there's material out there that's easy for them to understand, then they can see it's not scary.

(13:55):
So I think yeah, it can be a case of people putting themselves up there, making things look a bit scary, but it's our job as testers as well to try and bring that information down so that other people can use it as well.

Lina Zubyte (14:08):
I think it's very common with testers in general to simplify the problems. We find something and then we try to put in digestible steps, which is really hard. So if you see any bug report in any company, you may notice that people struggle to do that. People struggle to break it down. Having a skill of testing we have this power of likely understanding how to explain better, how to maybe teach better because we've been in so many situations where we need to break it down where it's extremely fluffy. And there may be also these cases, the siloed developer could be an example where they don't pair, they don't collaborate as much and it's not their fault, it's their habit, it is the environment. However, they may create a task or a bug which is straightforward for them and extremely fluffy for everyone else. And it does take confidence for someone to step in there and say, Hey, what do you mean here? Right? What do you mean?

Callum Akehurst-Ryan (15:13):
Yes, a thousand percent that. yes, that. Lots of the time and especially if you don't feel that you're technical or you are worried about coming across non-technical, and you might find this a lot with people who are minorities in engineering who may lack a bit of confidence, they don't want to come across as stupid, they don't want to give anybody any way to say, you don't know what you're doing. And people with imposter syndrome people, they're already worried about somebody going, you don't know what you're doing. So sometimes we don't ask those questions, but they're valid. So how do you learn if you don't ask questions? So yeah, I completely agree with that as a statement, just to be able to have that skillset of breaking things down, asking what do you mean rather than assuming things is so powerful. And it's a skill that I would say it's a technical skill that I would say testers should have. So in situations where you're coming up across an API, we shouldn't be scared to go, what does that mean? Can you show me that? What does it look like? What does it do?

Lina Zubyte (16:23):
I started a new project recently and there are so many old tickets that got stuck in testing and now some of them, for example, have been there for two years. So when you pick it up, it's so old that you're not sure at all what to do. And me as a newbie, I started looking at them and it is been really humbling and scary because maybe it's trivial to everyone else, but not to me. But I also may have this maybe privilege of being new to the company because I can ask and some other people maybe who were stumbling onto this issue, they were like, I have no clue. And they were afraid to ask and they didn't. Even though for some of those API requests, it's easy: you just provide me the payload, what do I need to send, what do I do?

Callum Akehurst-Ryan (17:11):
And what we forget is a lot of testers didn't go to university to study CompSci (Computer Science). Developers, engineers, whatever, will have gone through asking questions, but they did it at university so it's not as visible to us. So anybody's going through this learning journey and some of us, especially in the testing space, if we haven't gone to a CompSci degree, might just be asking now it might be the first time we're coming up against something, it's not wrong to not know something. So yeah, definitely I've been there as well.

Lina Zubyte (17:43):
Once we gain a bit of confidence, we can ask. So what are some of the ways that you would say we could test an API?

Callum Akehurst-Ryan (17:51):
Yeah, so the way that we test an API is to think about the risks inherent in them. So we've already said that an API is a conversation between two bits of software. One that's making a request, one that's sending something, say, Hey, give me this data, or hey, add this data to the database, and the other one going, yep, I've done that, or here's the data. So we can think about the risks inherent in that. What if I ask for the wrong thing? What if when I ask for something I get the wrong thing back? What if I ask for too much and it means that I can't get any information back. It crashes things. What if I send something and get something back that I shouldn't see? So a security issue. We can think about those sorts of risks and break things down.

(18:45):
So there's the ability to send data from one to the other. So what if I lose the ability to send data? I drop my network. What if the other system can't hear the data anymore? So those types of things. There's the request itself. So what if I send the wrong thing? What if I say in a language that people can't understand? What if I ask for two things at once and it can't handle it? And then we've got thinking about the response that comes back. What if that fails? What if it can't respond? What if it sends me back the wrong thing? What if it, yeah, like we said before, shows me something I shouldn't see? What if it transforms the data or there's hardcoded values in there? So we can break things down to think about the conversation. So the person asking, the person responding, and then the actual data itself.

(19:37):
We can think about things like non-functional areas. So performance: how long does it take to respond? What if I send lots of requests all at once? What if my network fails and recovers? Will it work then? There's all sorts of ways. If we just break it down and think of the risks of things that we can then start to test in those areas of, but if I was starting with testing, I think I would start to look at the happy path. So when you have an API, an API is made up of a payload that is basically sending, so a request that you're sending and a response. So you want to basically understand what does that request look like? It might be a JSON file, it will have a location to send it to and it'll have some data in that JSON.

(20:32):
So we want to understand: where do we send things to? What can we do with it? So that's that CRUD: can we create data on this: read it, update it or delete it? And then what do we fundamentally send it? So what headers and what data do we send to elicit a response? Once we've done one of those and we go, yes, we can request data or we can create data on this endpoint, we can then start changing the data in it and we can do all sorts of testing that way. So that would be your happy path testing and then you can build up from that. You can look at naughty strings, you can look at things like, ooh, can this handle Japanese characters? Could this handle emojis? Could this handle additional fields that we weren't expecting to put in there? What happens if I don't put any fields in there? What if I send it to a different endpoint, a different header like a URL effectively? There's all sorts of things that we can do in that way. That's how I would start using an API. So think of it as just like we say one system's asking another system for something - change what you're asking.

Lina Zubyte (21:40):
Actually, when I start looking at any system or an API, maybe I should start from documentation and just draft my own request and some tool like Postman or just scripting way in terminal. So these are the ways that you don't need a very fancy tool, it's free. But what I do is I just open the website, I open the dev tools, the network tab, and then I copy the curl and then I import it to Postman and then it actually separates the header, the authentication, I don't need to think about it. Then sometimes when the token expires, then I need to find out, okay, how do I generate this? Is it just basic authentication? What do I need for it? So just looking at your network tab, you can see those requests going and you can copy them and then import wherever you want and run them from your machine.

Callum Akehurst-Ryan (22:32):
Yeah. The way I first learned API testing was to start by learning what is an API and understanding that it is some requests, understanding that I can do the CRUD: I can create (read), update, delete or post, put, delete, read - get. I learned what the responses looked like and that each response has a code associated to it. So you've got your two hundreds for ok, your four hundreds for problems or errors, your five hundreds for critical errors, things like that. From there, and once I understood that you had a request going somewhere and data then responding, coming back, I started just like you did opening the network tab on your browser. So any of you who are listening who has modern browsers, you can right click and inspect on your browser and that will bring up your dev console in your browser.

(23:31):
There's a tab on that called network and it will start populating with requests backwards and forwards. And all of those are your API requests that your webpage, your browser is making somewhere to get data and you can start to have a look at those and see what they do. If you understand generally what an API request looks like, you can start to see the different types of data and the different endpoints that exist and then you can use those. So just like you said there to basically make your own requests. Another way of doing that is you can ask developers, what are the API requests? What does the payload look like? And half the time they've documented those for us or they have calls or they can show us what they look like or they might send us to something called Swagger. Swagger is basically a tool that allows you to document all of the endpoints with some example requests on them as well. And we can use those to just copy paste into whatever tool we want and play with that as well.

Lina Zubyte (24:33):
I think sometimes knowing all the possibilities can be a challenge a little bit, and you do need to ask a developer because not all this is documented. And then you may be testing one endpoint and it seems trivial, but then you could add five different query parameters and then get a completely different result.

Callum Akehurst-Ryan (24:53):
It's really true. Just understanding what's the purpose of it and what optional query parameters and why do you use it and when do you use it can be very tricky, but like you said, talk to your developers. They're there to, they should be able to help you with things or go full exploratory, try things, see what happens If you're in a testing environment, you can't really break things. So have a look and chase data through. The way that I tend to do things if I'm exploring is I'll look at the start off by using the UI, something that's easier to understand because we use the UI a lot, maybe put some things in fields, send that request across and then look in the network tab and go, ah, okay, this relates to this, this is this, this. See if there's any additional things there that weren't captured on the webpage. And then look about what comes back. Maybe look in the database, what was stored, what was returned and work from that, and then what else then shows on the UI based on that. So you can start to understand things by just chasing data through the system.

Lina Zubyte (26:01):
When it comes to API testing, are there some bug examples that you would have that you wouldn't have caught in the UI but you caught on API, what would that be?

Callum Akehurst-Ryan (26:12):
Yeah, some different ones. We learned that if your network fails that you can lose data. So if you start making a request and you are on a 3G network, you're not on wifi or the wifi drops, you can completely lose data from one thing to one service to another. So you might make a request, it all looks fine, but if the wifi cuts at certain points or the network cuts at certain points, you just lose that data, you lose it entirely and then the system doesn't like it. It's really bad if it's a banking app. So you might want to implement something a bit different from an API. An API is very like, I push you a request or I push you data or I pull data from you. So it's very one directional. You can have a two directional conversation, which is a web socket.

(27:03):
Web sockets are basically like APIs, but basically both services are able to just push to each other parallelly. So if your network fails, you can actually retry, you can bring it back on board. You can make things like fail and recover a bit better. So yeah, things that you usually bugs that you can find are around that networking thing. There are other things as well that you might be able to find out. You might be able to use your APIs to really hammer a backend service with lots and lots and lots and lots and lots of requests and do a load test. That's the best way to do load testing. See if you can bring down your services. They usually, the UI might be too slow to try and trigger off if you've ever done load testing where you tried to have 15 browsers open at once and send things all at the same time or try to organize everyone in your team doing the same thing at the same time.

(27:55):
That can be tricky. But we can use the API and basically just send lots of requests very quickly. You can get a Postman open, for example, make a request and submit it very quickly by slamming the button or there are tools out there that will do that for you. That's a really good way of performance and load testing something. Or the front end might do some validation and prevent us from sending certain things. It might have a title dropdown box, so it only allows Mr, Mrs, Miss, Doctor, Reverend, whatever, but using the API, we might be able to send different data. So therefore how does that respond? How's that handled as well? So yeah, things like that. There's all sorts of bugs that you can probably find by doing things. You can crash services quite frequently by sending data that things aren't expecting. You can usually get the UI to act really weirdly as well by forcing an API request. So if you can use the API to send a load of emojis with return characters into your database, it might make the UI render strangely. So yeah, there's a lot of things you can do with an API. It's very exciting.

Lina Zubyte (29:17):
Yeah, I always say that if there's an input field, that's an opportunity. We can absolutely try different inputs and do our boundary analysis and send bogus data and things like that. Two things that I'm hearing from your answer is first of all, that it could be much quicker to use an API, right? So we could, instead of filling in all those big forms, if we need to create many users, you could just do it via API and very easily do that. And the second one, this input validation, I think the one big learning from my mere testing career is also that there's frontend validation, there's backend validation, and then very often we have certain limitations not consistent. That means that if I'm using the API for the same purpose, I could abuse the system. So once I was testing the chatbot and in that chatbot because it was connected to the API, it was the chatbot for booking vacation days, I managed to book more vacation days than I had because in the UI I was not able to do that. There was a validation. In the backend, there was no validation. So as a result I was in the negative balance for the vacation days. So definitely APIs are quite helpful and we can find lots of interesting cases.

Callum Akehurst-Ryan (30:40):
Yeah. And that comes from all of your validation being at the UI layer, which is good. But also, yeah, you do need to protect against other things and then think about security. A lot of security testing happens at the API layer as well because that's a way that your man in the middle attacks can happen. So your threat actors, your bad people will probably attack your API to do exactly the same thing, make requests by bypassing the UI so that they can say, well, I don't have a password, but could you tell me all the people's details please? And maybe it'll give them to it. So yeah, it's definitely worth looking at those sorts of things there as well.

Lina Zubyte (31:20):
These are like nightmare scenarios for many products that you may actually expose some data that someone is not authorized to have and that likely is not seen on the UI. It's seen in the API requests.

Callum Akehurst-Ryan (31:35):
So it is a good layer to get into and understand because it just opens up so many more things for you. And where you said it was faster as well, it totally is because unlike UI, which will refresh and you'll lose all your data and then you have to fill it all in again with an API you can copy paste the request, the conversation that's happening to the API and just change one thing and it's just a lot quicker to just turn around data as you need it and you can save all of your requests and you can use them and you can send them to people to automate as well. So yeah, it's a really powerful thing.

Lina Zubyte (32:15):
Now we just crashed the surface of this topic, right? The API testing, what it is, but if people wanted to dig deeper and they wanted to start learning somewhere, what would you recommend them to look into and learn more about API testing?

Callum Akehurst-Ryan (32:31):
Yeah, so look up people who have blogged about it for some information about learning what is an API initially. I would point people to the training courses that exist on the Postman website. So Postman is a big app for API testing and development. They have a lot of training, a lot of online courses, a lot of information. It's a lot, so don't be scared, but yeah, definitely and reach out to people. If you go to a conference and you see people doing API things, reach out and talk to 'em again. It's really not scary. If you can use a website with a URL and if you can write a SQL query that has some data or an Excel calculation, you can use an API because all it is is a request and a URL, so you'll be able to do it.

(33:27):
So it's about getting confidence. Try downloading Postman or better, yeah, use your browser, use your inspect and your dev tools to pull up the network and start seeing what's happening with things. I've spoken a few times about adding APIs into your testing. So reach out to people. If you've got questions from people who've written blogs, reach out to them, like go on LinkedIn, go on Twitter and say, Hey, I read your blog about APIs, but what about this? Or I didn't understand this, or how do I go next? I want to do this. They'll probably write another blog about it and then you'll get the answers that you want. So do things like that. That would be my way of scratching the surface initially. Once you were comfortable with that, I would start seeing, can you push your testing earlier? Can you test headlessly? So can you test without UI at all just from the API layer? Because it's usually developed before we get a UI.

(34:25):
So start just making requests and visualizing what that might look like. You might want to do contract testing, you might. So that's between two different services. So we had those two different services that are having a conversation. Maybe one of them is a third party service and has expectations of what you're going to send it or what it'll send back. So you can test for that and say, am I getting the responses back I expect? That's a good thing to be able to do. And then you might want to start getting really cheeky and you might want to automate your API tests. Postman has awesome tooling built into it that will help you write automation based on the queries you've already created. There's a little tab there with a test section and it has little tests at the side and you click on them and it will write the test for you. So it might say, check that this is giving me a good response. Check that the API responds within 30 seconds, things like that. And you can then bake those in. That's automation. So yeah, you don't have to be using scary Cypress or anything for things. It's a good way to get started and familiar with automation.

Lina Zubyte (35:34):
And there's a great article written by you, which is about APIs. So we definitely are going to put it to the notes as well and all the other resources, what we discussed. So to wrap up this conversation, what is the one piece of advice you would give for building high quality products and teams?

Callum Akehurst-Ryan (35:57):
Don't be afraid to get in there, ask questions and surface information about testing and about the product. Like we said, you can get really uncomfortable not knowing things or looking like you don't know things. But that's good because it means that you can come and ask questions and make other people think about things. Assuming knowledge and assuming things adds risk to your product, because if everyone just assumes that an API does something, if everyone assumes a UI does something, well, no one's checking that. It really does do it. So never be afraid to ask questions or go, Hey, I've looked at this and here's what I'm seeing. Is that right? So if you want high quality products, start by asking questions.

Lina Zubyte (36:51):
Thank you so much. It was a lovely conversation. I truly admire your mission of making things less scary. So I'm sure that people who are listening for whom APIs look very scary are going to at least listen to this and go and check out some of the articles because we can start with little steps and it's not that scary. So thank you so much for your time.

Callum Akehurst-Ryan (37:16):
Thank you. Thank you so much.

Lina Zubyte (37:18):
That's it for today's episode. Thank you so much for listening. In the episode notes, you're going to find some resources about APIs including Callum's article. I really hope this episode inspired you to not be afraid of some concepts and dig in a little bit deeper there. Sometimes someone saying that something is too technical is a little bit gatekeeping, so stay curious and do not forget to keep on caring and building those high quality products and teams. Bye.


People on this episode

Head Shot

Lina Zubyte

Host