 Hi everybody, so nice to see so many friendly faces and I'm honored to be speaking to my community of practitioners. This talk actually started life as a presentation at the National Library earlier this year. It was part of our staff-led professional development sessions focused on all things digital and all things tech. And these sessions really aim to establish a kind of comprehensive foundation shared across the library of what constitutes digital literacy. It's to allow people to upskill, share knowledge they have, and even get people thinking about the role that emerging tech plays in the heritage sector. And I wanted to mention these sessions, first of all to give a shout out to like grassroots staff-led professional development because that has been like A plus amazing for me, but also to explain to you why I am the person here giving you this talk. It's kind of self-evident why Ting is here, as somebody who works with Digital New Zealand, she is deeply qualified to talk about APIs. But I am actually here because, though I'm a little more qualified now, at the time I was just straight up not qualified to talk about APIs. The people who ran the professional development sessions wanted to run an experiment to see that if someone who knew nothing could learn enough about APIs to explain them coherently to another room full of people who may or may not know heaps. And why did they want to do it like that? Well, because APIs are ubiquitous, whether we know it or not, we're using them pretty much all the time. So I think as people and as people who work with tech, we have a vested interest in knowing how they work. But there's also a lot of domain-specific language that is used to explain them and at least I found. There's a lot of confusing language used to explain how they work. And there's also a lot of kind of inexactitude about what we're talking about when we're actually talking about APIs. So this session is about bridging that gap between like straight-up tech expert and well-informed general user. So that's kind of what's going to happen. I'm going to give you a general introduction, talk about some of the concepts, and then Ting is going to like expand on some things. So what I'm going to do is I have one caveat. And that is that I learned about this in an almost exclusively web-only environment. APIs exist everywhere in software. They're across the board. But when I say API, I mean web API. And I'm going to use the words website and web application relatively interchangeably. And when I say that, I would like you to think about Twitter and Instagram and Google Maps. So very common web applications that you can access through a browser but that have a lot of stuff sitting behind them, stuff that people want to get at, like photos, tweets, geo-coordinates. And this is just a quick word on how I learned, what I learned. This is my YouTube watch history, which you can, so all I did to learn about this was I watched 50s of minutes of YouTube videos all titled things like what is an API? And yes, that was on work time. So what is an API? The Wikipedia page says, in computer programming, an application programming interface, API, is a set of subroutine definitions, protocols, and tools for building application software. In general terms, it is a set of clearly defined methods of communication between various software components. That did not help me at all. And it is actually on the other side of this, that is actually quite a coherent definition. But when I started my journey, that didn't help me at all. So I'm gonna talk to you about a few things that actually did. The first helpful thing to get me learning about this was a comparison. So I came across a suggestion to think about an API in relation to a GUI, the graphical user interface, which most of us know, refers to the way that we as humans interact with computers. So we double click on icons, we drag and drop, we type things into the browser, and it comes up in the Google search bar. So there's a whole bunch of systems and code and things there designed to structure how we interact with computers. So if the term graphical user interface refers to the systems that help humans interact with computers, then the term application programming interface just refers to the systems that help computers interact with other computers without a human there. Or in our case, web applications interact with other web applications. So machines don't need mice, they don't need drag and drop, they don't need a browser that you can see, but they need other mechanisms and rules for interacting, and more on that later. The other thing which helped me understand APIs was analogies. The most common one is that an API is a conversation between machines. One video I watched suggested thinking about APIs as a messenger that takes requests. And this is a quote, think of an API as a waiter in a restaurant. Imagine you're sitting at the table with a menu of choices to order from, and the kitchen is the part of the system which will prepare your order. Easy. What's missing is the critical link to communicate your order to the kitchen and deliver your food back to the table. That's where the waiter or the API comes in, end quote. I quite liked that one, I thought that was good because it helped me understand the kind of purpose of an API that it is to communicate separate parts of a system. But I still, and I don't know if you guys are like me, I wanted to know what an API looked like IRL and how to interact with one. Well, you guys, I watched a 56 minute video on how to build an API from scratch. And spoiler alert, it turns out an API is literally just snippets of code. Like snippets of code with a very, very specific purpose. What I learned is that when people say an API, what they're talking about, is just the part of the web application or website, that little bit of code that can talk directly to other web applications without human intervention. That's all. So to build an API is to code into your web application the capacity for data to be extracted from it or added to it in a machine readable format by other websites. So if you know what code looks like in any language, you know what an API looks like. And that's what it looks like when it's at home. So one of the things that I often found quite confusing was the kind of like an API, like the kind of nounization of that word. For me, it really helped when I thought of it more like a service you can provide or a capacity that a web application can or can't have. So when we're saying does that have an API, what we're saying is can we take data or can we put data into this website or web application directly from ours. So the API code, so the bit of the website that is the API, sets things out like this is where other websites need to look for data if they want to extract it from me. This is how I handle a request to extract information. This is how I handle a request to insert information. This is how I expect requests to be stated and that's an important one. Because if you don't write anything in your code that says, this is how I will handle a request for information, then other machines that make requests meet a brick wall and they can't automatically extract any of your data and have this little silo thing going on. And I think that's where the real like so what factor is. So if you're building an application that might need geo data, for example, well, you can either like create your own huge database of like geo coordinates or you can just plug in to the Google Maps API. So before I hand over to Ting, I just wanted to get very specific on one final point. So from the other side, to access an API, you make an API call and that's the request, the name of the request. And usually we don't see them because they are embedded in web applications or widgets. They live under the hood and that's part of their magic. They pass the data around without us seeing it. But funnily enough, like a lot of things on the web, they look really like URLs. And this is where Ting comes in. She is going to talk you through creating API calls and teach you how to manipulate one from your web browser. So I'll hand over. Kia ora. Thanks to Flora. Now we know that API is not something super scary from the metrics after all. I like that analogy that it's more like a friendly waiter at our local restaurant and it serves us what we order for a meal. And now it's just stuck in my mind to how I see digital and networks. So we have more than 30 million digital content that's contributed by our wonderful 200 plus content partners. And now I do see that we have a huge kitchen that is preparing all the digital content and through our API we're serving them the delicious digital content to our wider variety of consumers, they're eating them in different ways, consuming them in different ways. So for accessing an API first, since we're in the theme of keys, a key is very important because most of API providers require the users to have an API key. An API key is a long string of letters and numbers that functions like a password. So it's quite important to keep it safe. And I will show you a basic call that I made with my API key, which you will not see it. I have hidden it. This is from the Djo and Z API. And yes, I understand it doesn't look very user-friendly, just like us before our morning coffee. But this is considered very user-friendly for computers. So the Djo and Z provide a three-response formats, JSON, XML, and RSS. They're all very friendly to computers. For us, high maintenance humans, one waiter is far from enough, so we need extra servants. So on our web browser for our web-based API, we have handy extensions that we can install. It's called JSONView, or there's many other options as well. So we install that. And boom, it really helps us to see it comfortably with our human eyes. And it just shows clearly, oh, there's so many results I've returned. And you can see the first record is from papers past. To filter the millions of results that have returned here, you can manipulate your API call with parameters. Another difficult term for us humans. So parameters is the information you can add to the end of the URL. And it defines your search. To a waiter, you need to give them the waiter information. What do you want? How do you like to serve? Would you like to be complicated? No problem. So we add extra parameters. And so how do you know what kind of parameters you can add? So like a restaurant, you have a menu, and you can order what is available. Most API providers also offer detailed documentations to help you to construct your API call. Here's a scary list of some parameters available for the digital Z API. And there is even more. So do check it out on our website. And I do understand the API documentation looks but daunting because who likes to read manuals? I don't. But I learned the hard way. So you think as the restaurant scenario, everybody likes to read manual. No, sorry, my English. It's OK. But you want to find food. So you read a manual. And think of that way because you want to get something. You want to consume something. And it will really help you to understand what an API can offer you. So for digital Z API, we have a format to construct the API call. I know it looks like, oh my gosh. But in plain English, it basically says the URL to our API, the version of our API, and which API call from digital Z because we offer more than one. And the format, we want to see it to present. And lastly, define what you want to search. And yesterday, I was talking to Sarah about creating Twitter bots for a dog. Well, I'm a dog person. I mean, sorry, cats. I'm a dog person. So I want to create an app to showcase all the dog images I can find from our API. So I will make it bigger for you to see. So I would use the parameter called text. And then I want to have all the dog, dogs, doggies. So I add that little star. I know it's not the right name, but I can't pronounce it. I practice so many times. But yes, and I want to limit it. I want to limit it to the category. As you can see, there is another parameter. I want to limit it to images. And then here, I can, sorry. And then this is already being limited to images. And I still feel like it's showing a bit too much information for my brain to sift through. So we can limit the number of fields that's showing from the API. And we can just continue adding more requirements, more parameters at the end of the line. And to reduce the number of fields. So here, I have reduced to only show the content partners who contribute most dog images. And this is basically how we do our metadata battles. I don't know if you see some of our Twitter. And we just compete for you, our dear content partners. So we just pick the first two content partners that who holds the most content. And we decide the winner. And here is ATL. Good on you. To make our life even easier, there's so many fantastic organizations that really do everything to support everyone and anyone who wants to use their API. Two of my favorite API provided by Auckland Museums and Tipapa. So the Auckland Museum API have completely removed the requirement for an API key. Completely removed it. I was mind blowing. And for anyone who's interested, you can just go ahead and give it a go. I feel, for me, I'm not super expert on API. And I feel, without the key, it's just more inviting and it feels less scary and more comfortable. And the formula from DDoNZ API can quickly translate with, even though it's a different term, it is quite easy to read. So this is a basic search I've done from the Auckland Museums API of Search on Skytower. This is the only thing I know about Auckland. Sorry, Auckland. So they have a search. And that's the endpoint which you can use to perform sophisticated search queries. And then after you have the name of the search index that I got searched from. And then the underscore search is the operation we want to perform. And again, the Skytower is now under the Q that is query parameter. So it's quite similar to DDoNZ API once you know the formula is quite similar. And then again, we can add extra parameters to change the size and then change the pages. That show from the 20th record. And so on the other hand, T-PAPAs API, even though it has a key, hint, hint, maybe we can remove that as well, have solved one of my biggest fear, I don't know of other people, is I'm a very visual person. So the T-PAPAs API browser has kind of transitioned from just the API to the GUI field. And it really made me feel even more comfortable. And so instead of you have to learn and type every parameters out, it is, boom, you can just drop the, what is it called? They drop down menu and then select them. And all the complete API code will be constructed in front of your eyes. Oh my gosh. So this is all learning curve for us. And I believe there is going to be more wonderful things like T-PAPA and Auckland Museums doing. Henten DDoNZ team. So we need to make it better. So just remember that we were once you, not long ago. And you're definitely not alone if you're confused. And so worried about this, we can learn it together. Does anyone have any questions for Ting and Floor? Any questions? No questions, good. I have a question. I really want to make this Twitter, but yeah. So what would your advice be to someone that wants to use, doesn't know anything about APIs, but wants to make something? Read the documents. Read the documents. And just give it a go. Sorry, maybe I should have it then. Just give it a go and construct your API core and see what you get. And I don't know. So you want to create a Twitter bot? A competing one against yours. Oh my gosh. I have not started mine. I've not started mine. And that would be my new project as well. Yes. Yes, yes, yes. Any other questions? Hello, I hate microphones. How do you actually get a hold of an API? So it's like, oh, I want to go get an API. As soon as I leave this room, how do you do that? Sorry, I missed what you said. If I wanted to leave this room now and get a hold of an API, how would I do that? Well, the Auckland Museums, one, you can just search API Auckland Museums. And you will just be able to start using it. And for Dejo and Zed, you can go to our website and register for API key. Deepappa, I'm not too sure at the moment, we got private key. Yes. I'm sure Deepappa will give you a key if you want. So through a web browser then? Yes. OK, cool. Yeah, if there is one thing that you should take away from this talk, it's that you can learn anything from a YouTube video. Because there was one that I watched which was really incredible, which actually just talked to you through in about nine minutes what it was to build a small web application which took photos from, no, you searched something. You searched a place and then it would return all of the photos from Instagram, which had been taken at that location. So what it did is it took your tiny little input. It went to the Google Maps API, geocoded it, sent that to Instagram, and then returned the photo. So this is a really short video. And the guy built this whole app in front of you. And what that did was also went through the kind of attendance skills which you might need to embed an API call in a really, really small website. And then I discovered that, yeah, you can just go to Digital New Zealand, get an API key, and then you start building these calls in your web browser. And then you can see it happening in front of you. And it's incredibly empowering. And I was just like, wow, look at me go, like getting all of the records from Auckland Museum. Ta-ta-ta-ta-ta, like, yeah, that was great. Thank you. Not a question, but more of a statement. Those web applications and everything. It requires scripting, and that's the bit that I hate. If you can find the script there and you just need to adapt it, it's the way to go if you're not too good on scripting. Yeah, and? You choose the one you want, the right script. Yeah, I mean, like as I said, the attendance skills can be another barrier to be able to engage with this stuff. But yeah, maybe a Google search where we'll find somebody who's done the work for you with that script, yeah. Hi, that YouTube clip sounded really good. And knowing how hard it is to find things on YouTube, could you share via Twitter the link to the YouTube clip that you talked about? Yeah, yeah, yeah. And hopefully my ringing endorsement of that YouTube video won't be misguided. Oh, she can say, we can repeat it, maybe. Yeah. So if you're doing a search on one API and then you want to perform it on, so you're doing it on to Pappas, and then you want to perform it on Auckland museums, are you having to learn a whole different set of rules, or is there some kind of level of compatibility between them? I, unfortunately, I feel like it's more or less, it is different for some of them, yeah. So, again, go back to the document. You really have to look through the document. I really learned a hard way, I really did. First, I was very comfortable with the DJI API, and then I wanted to just explore more on the Auckland museum one, and I was like, oh, they're different. So I read documents. Yes, I just constantly have to remind myself to read the documents and to find out what actually is on offer, yeah. Yeah, I mean, they're kind of the same bit different. Like you have the beginning structure, which is like the little address where the API actually lives and you're talking to it, and then there'll be kind of a symbol, which means this is where your query starts, and then you, like you can put in the different parameters for what you're looking for, but they'll, so there's the kind of, yeah, similar structure, but yeah, different flavours, and as tanks here to read the document. Yeah, because they're really helpful.