 Hello everyone and welcome to this Euclidator Service webinar on what are APIs. I'm Marguerita Sarrala and I'm an Outreach Officer working for the Euclidator Service and based in Manchester at JISC and presenting today is Peter Smyth, he is a Research Associate at the University of Manchester and he's working within the Euclidator Service training team. Okay thank you Marguerita and just bring up my PowerPoint slides, there we go and welcome everyone for joining us today. In this webinar as we've already said we are going to talk about APIs. So the overview is we'll describe what an API is, I'll give some examples of APIs. We'll discuss how you find out how to use an API using the provided documentation and then we look at a browser based demo of an API and some code based demos of APIs. So first off let's have a definition from Wikipedia. An API is a set of routines, protocols and tools for building software applications. In fact it's wider than that because it's not just software applications it's really about how applications talk to one another or how people talk to applications. It expresses a software component in terms of its operations, inputs, outputs and underlying types. Operations, inputs and outputs are the key points here. We're defining how you talk to, how you make requests to an application and how the application is going to respond to those requests. It defines the functionalities that are independent of their respective implementations. Now what this means is that if I was to take an example, if I was to ask, make a request to sort a set of numbers, then the response I would get expecting it back is a sorted set of numbers. But at no point do I try to influence how that set of numbers is to be sorted. And in the background there's an overlap of sorting algorithms which could be used but we don't really need to know that from the API point of view. We just need to know that if we make a valid request to sort a set of numbers we get back a sorted set of numbers. A program I can use in API to build an application. Absolutely true but in our case because an API isn't just about applications talking to applications. The type of API we're going to be particularly interested in is where we as end users with the help of our PCs and some program encoder or whatever are going to make a request to another application whether it's a web server or a web service and ask that application for some data. And it's a data that comes back that we hopefully want to make you solve in our analysis or research. So to put it in another way, more succinctly, an API hides complexity of the implementation and using the API allows the implementation to change without affecting the users. So let's have a generic API in terms of pictures. We have application A and we've got application B. Application B makes a request of some kind to application A and application A gives a response. It's that simple. The actual API part of that diagram is the request and response in the middle. Application A and application B just need to understand the APIs. And application B in this case isn't necessary a software application. It could be you an end user typing something into a web browser, for example, or it could be program code that you've written. So let's consider within this API which part you need to know what information. Well, certainly if your application B you need to be able to correctly format the request into some predetermined, pre-established set of requirements. You're going to format the request and you've got to be able to send that to application A. When application A gets that request, it needs to understand what it is you're talking about and at the same time it needs to collate the response to that and send that off to application B. Application B, when it gets a response, it needs to know how to interpret that response. Let's consider what you don't need to know or who doesn't need to know what. Application A, who is receiving the request, doesn't need to know what application does with the response. In fact, application A doesn't even need to know who or what application B is. On the other hand, application B doesn't need to know how application A creates a response from the request. This is similar to, this is a bit like the example I gave before with the sorting of a set of numbers. As long as the response has the sorted set of numbers, application B doesn't really need to understand how application A actually created that set of sorted numbers. In specific cases, application A is typically some kind of web service or website itself. It could be a simple website just returning web pages. If you think about it, if you put in a URL into your web browser, a full URL, you expect the web site that you're sending that to, to return you a nicely formatted page of information. So that is a very simple version of making use of an API. If you don't ask for the right page or you get back the page which you specify in that request to the website, you could also just be asking for a stream of data in response to a search request. This is probably a situation where we're more interested in. Rather than actually wanting some nicely formatted web page, we just want to make a request for, I need information based on this set of criteria and then the response comes back and there's just a stream of data coming back to you and then it's down to you to interpret that data correctly and make best use of it. So that's application A. Application B, which is the user side of things, it could be anything. A smartphone app, unless you're actually listening to local music or watching local video, almost all smartphone apps make use of APIs to connect to some kind of web service in the cloud. So when you're, say, on trying to look up train times, you put in, say, I want to go from station A to station B, that information, the answer to that question, if you like, isn't on your smartphone. That has to be formulated into a proper API request and sent off to some application like the train man or whatever and then the response comes back as a stream of data and then it's your smartphone app which makes it look nice on the screen and make it easy for you to read. Application B could also be a simple web browser. It could be some kind of development tool or could be program code. There's probably more as well. But the last three we'll actually see examples of as we go through this webinar. So pictorially, if you like, we have application A, application B. We've got various requests and responses going between them and application A, as we said, could be just a website or it could be web services. Application B could be your smartphone. It could be program code. It could be the development tool or it could be a web browser. Like I said, that's not meant as an exclusive set of options there. But the point is the separation between application A and B is they don't need to know who's talking to whom and so on. They just need to be able to correctly format a request and understand the response that comes back. And this is really what leads to the flexibility of APIs. Although the format of the request and the response is fixed and very rigid, well documented, doesn't change. That's why it is such a good tool and API because the structure doesn't change. But behind the scenes, the requester who's making that request, as we saw in the previous slide, could be anything from us to you typing in code on your keyboard to some kind of smartphone app. And equally, the responder, as long as it understands your request and is able to respond to it, how it actually creates that response is of no real interest to you. So that can be changed over time without it affecting how your, say, smartphone app works. If you think about it, if that wasn't the case, if we didn't have this rigidity over how the API actually communicate between the two applications, if anyone changed the web service application that your smartphone app was pending on, whenever they changed it, you'd have to get a new version of the smartphone app. And that's not really very practical. So, some examples of APIs. Well, I'm sure you're very underpriced to know, Twitter has an API and Facebook has an API. But a lot of other people do as well. The Met Office has quite a simple to use API where you can get weather forecasts and the like. The Guardian has an API where you can get information about articles, you can search for terms and what have you. And that's going to be one of our demonstrations in a few minutes. There's a transport API, which is actually a generic organization which collects information about all transport systems, I think, in the UK. And again, you would use that by asking specific information about some type of transport in some location and so on. And we'll see that in a minute. Google Maps, I've said Google Maps, but Google in general have a whole host of APIs. Google Maps just being one particular example of it, or one particular example of an API they have. And that allows you to send information that your coordinate, your long shooting latitude, and it returns you a little map segment which you put on your web browser or show in your web browser or other application. Interestingly enough, the general tech search API from Google is now depreciated in that they don't actually maintain it as such. But of course, every time you do a Google search, your search term becomes part of an API called Back to Google, who then returned the set of results for that search. So it's still there, it's still an everyday use. It's probably the best example of using an API where you don't realise you're actually using one. So how do you use an API? It's really very simple. You make a request, you get a response. The reason why it's not really quite that simple is you need to decide how to formulate that correct into something which the API is going to accept. And when you get a response, you need to work out how to interpret that response. So if we look at the transport API, as I mentioned before, this is an example of a call to the transport API. And you can read that if you like, I'm not sure how you'd read it. But you can see in here, there's little things like bus and stop and live HTML and roots and API key and app ID and so on. All this information is what you get from the documentation and you'd need to know how to construct that call before you can make a valid response, valid request to this transport API. But you should be able to get all that from the API documentation. And then when you get the response, it looks like something like this. Now, for those of you who have done any kind of programming, this may not look too bad. It's in a JSON, what's called a JSON format. And it's sort of readable. You get the idea that, oh, we're talking about a bus number, perhaps 243 going towards Wood Green in London, or your TFL Transformer. You can sort of interpret but it's probably not really what you'd want to end up with on a screen in application. It's more likely that if it's coming back in this form, you may want to make use of this to extract information for further analysis and so on. Perhaps combine this with data you're receiving from other APIs. So I've already mentioned API documentation. It is absolutely essential to read and understand the API documentation. Basically, all of the APIs will have documentation somewhere. It's just a case of finding the right set of documentation for your API, which you can typically find by saying Google Space API or Guardian API, and it'll come up with the API information. We'll look at that in a minute. Why you need to know the API documentation? Well, the first two bullet points here, you need to know how you format requests so that the other application understands it. And exactly how you do this quite likely will be in the API documentation. You also know, as we've seen from the last two screens, you need to understand how the format and what is likely to be in the responses which come back. The response in that previous slide is a clear response to that request. But if I mistyped something in that request and couldn't understand it, then this response may be completely different, effectively just giving you some kind of error message. So when you're looking at the documentation, you need to understand not only what a correct response looks like, but what it might return in terms of errors and things like that. Now, the other things you need to know about APIs when you're starting to use them for programming and things like that, or writing your applications, is that quite often, the API provider will expect you to use a key which you have to sign up for. Typically, the keys are free and they'll give you some kind of usage of the API. There may be limitations on that use, but again, all of this information, how to get a key and how you're going to be limited in using that key will be in the API documentation. So certainly, if I go back to this one up here, you can see here in this transport API, there's an API key and some long key value there. And that's quite typical. Most APIs will require this sort of arrangement. So if we look at an API, a specific API, this is a Guardian API, it's a Guardian newspaper. It's quite good for a couple of reasons. One of which is it's quite simple. And the second thing is it's got this open platform to record explore, which allows you to experiment with this API in your web browser and get a feel for how it works and what kind of results you're going to get. So I'm just going to show you a little demonstration of that. If you go to the open platform, the Guardian API, you'll get to this page quite happily. This is where it's going to describe the first page of the API documentation. If you click on the documentation here, it will take you into far more details of exactly how to construct queries and types of parameters you can use, how you can use filter operations and then also build up complex queries and so on and so forth. So everything you're going to need to do in order to construct a valid request to this API is in this documentation. And you can go through that at your leisure if you're looking to use this. But if I just go back a page, what this page also tells me is that I need to register for a key. And that's just a simple form filling exercise. We won't go through that. And at the bottom here, it will tell you as having got your key as a developer, this is what you can expect from the API in terms of limitations. So you can make up to 12 calls to this API per second, which is clearly aimed at some automated process rather than new typing. You can have 5,000 calls per day, you get access to the article text, and there's one three quarter million of those. If you are prepared to pay, and again, some of the bigger API providers will have a commercial aspect to them, and you can get it effectively just more if you're prepared to pay for it. But for simple requests, and certainly when you're starting off, a free developer type key is probably going to be more than what you need. So the next thing that we have in the guarantee platform is this button up here, which is labeled explore. If you click on that, what you get is effectively this is a little application in your browser. And this application is going to explain to you or help you understand how the Guardian API works. So up here, we're going to put a search term. So today, we're going to use, because it's quite topical, Brexit. Right. Now, as I was typing that, or as soon as I finished typing that, you can see down here where it has actually constructed the API call. So we've got a normal URL typing here, we're saying search, question mark, query is for Brexit, and we've got an API key, which is test. We're going to use rather than actually applying for our own API key, we're just going to use tests for these examples, because we can get enough information back using the test key. Okay. I can if I wanted to, I can add filters for sections, tags and all the various things. So you can use this screen to actually build up requests to the API. And it instantly shows you what data is going to be returned within the API. So you get some basic information there, then you've got a result of 10 articles on Brexit, which are coming back. And tells you that is an article, various bits of information when they were published. And it even gives you a web URL. So if you click on that, you will actually, if I just do that and say open the link in a new tab, it will actually take you to that page. That is a live link. So that's quite good. That's a very useful tool if you want to use Guardian API. The problem is very few API providers will provide you with such a nice tool to allow you to get a feel for how the API works. You set the law to provide you with documentation and examples perhaps, but they won't actually give you a nice little tool like this. So what you can do, just go back to the slides. What you can do, you can use a tool called Fiddler. Fiddler was developed as a web development tool. And it's open source and it's free. You can download it and install it on your PC. And it's capable of a great number of things that web developers typically want to do to test things out and try this, that and the other. From our point of view, we only want to be able to send requests to an API and examine the responses from that API. So that's rather limited. So when I show you Fiddler here, you can see it's a very crowded, cluttered sort of screen, which might be a bit off-putting for those who haven't seen this sort of environment before. But we're going to make very simple use of it. If I just go back to my Guardian, this example, which we constructed with Brexit and API tests, I'm just going to copy that and go back into Fiddler. And if I say composer, and in there, I've already left it in there from last time, we've got that same API call that we've just constructed in the Guardian Explorer. And I'm just going to execute that request. And nothing appears to happen in here. But on this side, you can see that it's made the request. A result of 200 is good. That means it's equivalent of OK. And if I double click on that, and the bottom of the screen now, you can actually see what was returned in terms of the data. And Fiddler knows it can work out that this response is actually in JSON format, as I think I might have mentioned before. But certainly the Guardian response is in JSON format. And it will actually neatly lay out this JSON for you just so you can see all of the data which was being returned. And the fact that this, the layout of this is almost identical to what the Guardian Explorer little tool does. So it's doing much the same thing. The advantage of using Fiddler is that this will work for any API, i.e., all of the ones which don't provide you with that nice little Explorer tool. You still have the problem of, well, how do you read this JSON, and what can you do with this, and so on and so forth. But at least it'll give you a far clearer idea of what is actually being returned. And equally, had I got that response, if I'd got something wrong in that request, so if I try and do it without an API key, for example, and say execute, and there you go. I think it's probably that one there, 401. 401 is error code for not authorized. So if I double click on that, it will tell me that there's a problem with it. So even then, even when you get things wrong, Fiddler will actually tell you exactly what the other side will say and give you some kind of interpretation of it. So Fiddler, a useful tool if you're trying to use an API which doesn't provide you with a nice little Explorer-type tool as in here. So back to the slides. That's Fiddler. So let's look at the example from the Guardian. We're going to use our programming language for this. And what we're going to do is we're going to format a request, as we know we have to do. We're going to send that request and get a response to it. And then we're going to look at, we're going to pass that response and extract the web URL. The web URL was that link I clicked on before to get the actual page to come up. And then for the set of results we get, we're going to collect all of those web pages. And then just for fun, we're going to create a word cloud, all in all. So if we bring up R, let me just clear everything I've got in there in a minute. OK, Guardian R. I'll quickly run through this. It's not meant as an R teaching exercise, but basically I've got a load of libraries I'm starting up with. Just a bit of housekeeping type stuff for the graphs, the charts I'm going to draw, or the word clouds. I've set my search term to Brexit. I could obviously change that to anything I want. I'm going to make a call to the API here. So this line here is going to make my, is actually just setting up the string of the request. So it's just going to put this information there. So if you move along here, you can see it's, I've got my search term in there, and I've got my API of testing there. And then this next line, line 18, is actually going to make the request, get the results back, and put the results into this response variable here. And then because we already know it's in JSON format, we're going to use a function called from JSON to read that response and create a data frame from it. And then from that data frame, we are going to extract the, it's rather a convoluted way of doing it, but from that we are going to extract the web URL. And we're going to make sure it's got an S on the end. And then for each one, we're going to read the, we're going to use something called html tree pass, which will again make a request for that web URL, and it will get the results, and it will store results in doc.html. We're then going to just manipulate that to get rid of stuff we don't want. And then we're going to, this bit down here is going to be the word cloud. So let me just clear my previous examples there. And what I'm going to do, I'm just going to run all of this together, because it does run quite quickly, this one, hopefully. And so you can see down here, as it starts getting these 10 pages back, it's making little word clouds of the various words in those pages. And I don't know if you haven't seen a word cloud before, the size of the font, if you like, represents in proportion how often those words are occurring. So consequences is obviously the most frequently used word in this page, and things like just is used less often. Obviously, this is just as a demonstration. In reality, you could use this to do frequency counts and all sorts of other things. So that's using the Guardian API. Oops, it finishes that one. So the next one we want to look at is a Twitter example. Twitter, I think, is possibly one of them all complicated APIs, not only to understand because there's so much of it, but also by virtue of the fact that you need to have a set of four keys before you can use it. And you can only get keys by creating applications from starting at this point here. And you can't create an application unless you've actually got a Twitter account. So your first step is actually creating a Twitter account. Then you can go there and create what's called an application. There's a simple form filling in. I'm not going to go through that now, but we will hopefully provide you a guide on how to do that. But basically, you end up with a set of four keys, not just one. And in Twitter, we've also got another decision to make because when you want to retrieve tweets, you can either make a search of what's called the recent database of tweets, which is maintained. And typically that's about seven days, the last seven days of all tweets. And you can say search within there to extract tweets on whatever subject you're looking for. Or alternatively, you can use what's called the streaming API to capture tweets as they occur. And the thing about this is that only about one percent, a one percent sample is actually made available to you. And obviously there's no guarantee you're going to get all of the tweets which actually reference your search term anyway. So whatever methods you're using, what you've got to remember about Twitter and retrieving tweets is you shouldn't really have any expectation of getting every tweet with that search term in it. It's only ever going to be some kind of sample. So our first search of Twitter, we're going to use our code again. We're going to use a line. It'd be called Twitter, surprisingly enough. We're going to need to set up our authorization using the four keys that we have. We're going to again search for the keyword Brexit. And we're going to do this separately over four different days. And I'm going to save the text into a single data frame, extract the hash tags from the tweets and again just create a word cloud to show what we've returned. So back into R. Let me just clear them out. I'm also going to clear out all of them to start afresh. If you're wondering what these 30 warnings were, it's because if you don't make the greed or this pain large enough to display the word cloud, it misses out some of the longer words or some of the words. But again, for example, that's not something we're terribly concerned with. So let's just look at some of this R code. Again, this first part is just setting up the libraries and the color pallets. This section down here, which I've commented out is how you would set up your API, your keys. So you've got something called an API key, an API secret, an access token, an access token secret. And when you've got all of them and put into these variables, you then call set up Twitter OAuth, which is part of the Twitter library to set up your access into Twitter. And from then on, you can actually just do things like search Twitter and then give it instructions of what you want to search. So if I just run all of this up front, just in real time, you can see up here where the access token keys have been put in place and so on. So they've been used to create my authorization into Twitter. The next bit I'm going to run is I've got separate lines here for each day for four different days. So I'm searching between 21st and 22nd, 22nd, 23rd and so on. So I've got four days of search to say. And what I've said at the end is I want to put n equal to 1000. That's the number of tweets I wanted to return. So in each case, I wanted to return 1000 tweets. I'm just going to set that off because that won't take a minute or so to run. And while I'm waiting for that, let me just explain that this n value here, you can set it up to 5000 and it will return 5000 up to 5000 in one call. But the way I'm running this one after the other like this, if I try to do that, what would happen is that I would actually run into the limitations that Twitter imposes on me for my free access using my keys. And what happens in the case of the Twitter R library and using search Twitter is that it will run as fast as it can. And then it will... Let me try and show you. What happened? This is one I tried earlier when I had n set to 5000. And the first three worked quite happily. And then on the fourth one, well, I ran into a snag because there's a rate limited, blocking for a minute and retrying up to 119 times, which is quite good because eventually when it got down to 110, it was my rate limited blocking was over because it's time related and it was able to get the last set of 5000 tweets. This is an example of an AP... The package, the Twitter package in R is very good in that it will do this for you. There may be other packages which might just say, well, I asked for 5000 and it just sent me this error message. Here's the error message and you have to deal with it. So it's quite good because you can actually just set this off and go away and have a cup of tea. And even if you've got to wait an extra 10 minutes down here, you do eventually get back what a day is you're hoping to get returned. So that's all finished. So all I'm going to do, I'll just run these all together because basically on day one, I'm just running day one and I'm going to create a word cloud as I did before and then day two, I'm adding day one to day two and then day one to day two to day three and then finally for day four I've got all four of them. So if I just run that like that, as that runs through, again, I'll start getting word clouds for and these are word clouds based on the hashtags of all of the tweets that I returned. And given that I give my original search term was brexit, you can see that obviously vote leave is very strongly associated with it and strongly in, which is the other side and EU referendum. So things that you might expect to be prominent are indeed prominent. But again, obviously this is just for demonstration. You've got the tweets coming back. What you do with them is going to be dependent on what your requirements are going to be. So that's in the VAT example. We've got one more example to go through and this is going to be, what was it? R code. And now we're going to look at streaming Twitter and we're going to use Python code for here. We're going to use something, well, not quite as adventurous perhaps. We're going to use a package called Creepy, which is a Python package, which again, freely available like Python itself. You just download and install it. You still need your exact same four authorization keys. And then what we're going to do is to search again using brexit, we're going to get some tweets and we're going to return these and we're going to write them to a file. And at the same time, we're going to write something on the screen just so that you can see that this is happening in real time. So where do I want it to be? Not there. Explorer, right? This is the Python code. I'm running this in as a Jupyter notebook. Again, for those people who use Python, you're probably familiar with that. For people who don't use Python and thinking about trying it, then using Jupyter is very, very useful in terms of helping you develop in small chunks of code. So at the top here, I've got a small chunk of code, which I'm good at from some import statements from Tweepy to get hold of all the things I want. I also need to import Jason and IO as well. If I just click on that and just run it, it has run. You can tell about that four up there. But there's no actual response, so it doesn't really show you anything different. There's no output from that. And equally here where I'm setting up my four keys, and this bit of code down here is effectively saying what I want to do when I get a tweet back. The tweet comes back in this variable here called data. And what I'm saying here in these three lines is our four lines. I want you to show me five lines, if you like. I want you to read the data, the tweet that's come back. I want you to extract the text from it, the created art date, time, and who did it, the user screen name. And I've called them tweet name and user time. And I want you to print that on the screen. And also, in addition to that, I just want you to take the whole tweet which came back and write it to this file here. Now at the moment, that file doesn't exist. It's going to write it into this folder here. So again, this is just set up information. So I'm just when I run that, this changes to a file to say it's been run, but there's no visible effect of that at the moment. It's this last section here where I set up my authorization keys using authorization to Twitter using my keys. And then I set up a Twitter stream saying I want to use my authorization keys. Listener is this section up here telling it what to do when you get tweets back. And then finally, I'm putting in here, I want you to search for tweets or listen out for if you like tweets which contain the word Brexit. So when I run this one, then you can see here, this is just shown as an asterisk because it's still running. And in a minute or two, oh, oh dear, it's broke. Well, that is very unfortunate. Oh, certificate verified fail, certificate verified fail. OK, most unfortunate. What I'm going to do is I'm going to close that down and try it again. Just bear with me for half a minute. That could be the problem, but it was already closed down. Um, right. So this is a live demo, obviously, which is why it's not working. Just bear with me while I try this again. Um, where do I want to be? Um, Brexit. Right, try this again. Um, and then that one. And that one. Run this one. Oh, no, it's failed again. Um, OK, I think I'm going to have to stop at that point. That doesn't seem to want to work. I think what we'll do is we'll try and set that up as a little bit of video and provide that on the website. Um, what it would have shown you is, instead of this error message, it would have shown you a bit of text with the tweets in it and who sent them and when they sent them. And in our, our folder up here, it would have actually collected all of the data from the tweets. And the point about doing that or demonstrating that is typically what we selected here, texts created out in screen name, are things that you will typically want to extract from a tweet. But the reality is that a tweet consists of an awful lot more of information. And when we're storing into the file, then you actually store the whole tweet. And so if this was actually working, you'd see this file size increasing. It's three or four kilobytes for each tweet that is being recorded or being saved. OK, so I'm not sure what has gone wrong there, but like I said, I look into it and we'll produce a little video with that example on. Sorry about that. So back to the slides. I think there's only a couple left. So folks, that one didn't work. But you have to decide which approach is going to be most appropriate to you. Whether it's OK to just search within the last seven days on a regular basis, perhaps, on a daily basis. Or whether you want to actually stream tweets as due in a sort of live environment. So if you do want to scale up, and this applies to any of the APIs that we've looked at all, the ones we haven't looked at, you may want to extract data from these APIs on a regular basis. And the way to do that, you'll have to just think of a couple of things like scheduling a regular request. Running your search Twitter program once a day or something like that. And you don't want to be locking in and typing this all in every time. So you may want to automate this in some way. So if you're using a Linux type system, you can use Cron to automate it. Or in Windows, you can use something called a Task Scheduler, which is on all Windows desktops that's just a very rarely used sort of bit of application, which you can use to set up to say, run this program at eight o'clock every morning, assuming the machine's powered on. A more simplistic way is that you can actually start the program yourself and then within the program have looping code, which just says finally 5,000 tweets, wait an hour, and then loop around and get another 5,000 tweets so that you don't ever run into your time limits or restrictions and things like that. The other thing you might want to do is we sort of showed this in the Guardian example, where we started off by using the Guardian API to extract information on articles related to Brexit. And then we used the information that came back to make a further call, not to the same API, but to the standard web page API to get a web page to come back. And then we extracted data from that. Now you can easily imagine that for other APIs, you may start off with a certain set of information, you pick something out, you may use that to formulate another call to the API and so on and so forth. So you can imagine how depending on your requirements and the coding may in fact become a little bit more complicated. So it's something to think about. And then lastly, as we thought we didn't quite see in that streaming Twitter example, if you're going to start collecting lots of data from APIs, especially the likes of Twitter, which is quite verbose, then you may want to persist that data, it's not just gonna be in your little session that you're running, you may want to write that to a file as I was trying to do there, or you may want to write it to a database or something like that so that you can subsequently make use of that and do the analysis at some future date and you've got a persisted storage of what it was you collected and when you collected. And then the webinar we're doing next month is on a database called MongoDB, which is quite often used to record information from the likes of Twitter, things which comes back in JSON format. But there are other options like SQLite if you're using R and so on and so forth. So again, depending on your use case, you may want to need to consider how you're gonna persist the data for future use. Finally, books on APIs. The problem with APIs is that, as we've already said, you really need to use the proper documentation for the API that you're hoping to use to find out exactly how to do the things that you might want to do. But having said that, things like the Twitters in the Facebooks and all the common social media APIs, they're not only well documented by the providers, books do appear which will give you examples of how to use them. So in this first one, this one is based on our mastering social media mining with R. This will certainly give you examples of using the Twitter API in the Facebook API, I think, and several others and general searching techniques using APIs and web pages and what have you. And similarly, this one is for Python coders. And again, it will again give you examples of how to use the Twitter API, how to use the Facebook API and several others from what I remember. But they'll give you, they're good if you just want simple examples and you're not very familiar with the languages that they're using. But they're not really substituted for actually going to the API documentation and having a look at that to see what's in there. But it'll get you started, certainly. So I'd just like to thank everyone for joining. I hope you found it useful. And there's more information on our events pages if you want to attend other webinars. For example, the MongoDB one. Thank you very much again. Thank you, Peter. And have a good afternoon. Thank you. Bye.