 So, hello everyone, I am going to talk about open event API, as has been already covered by Mario Niranjan and Saptak said, open event is a very large project, it has lots of components, the Android app, the web app, the Android app generator and we have the open event management server, the event management server. So, I did the API part as a part of GSOC project last year, so I am going to be talking about that, before starting the presentation, let me give you a brief background about me. So, I am a third year computer science undergrad from Triple I.D. Kerala, India. I have been doing software development since 2013, actually that time I was on Windows platform, so there was a scripting language called Autohorkey that I had learned and just after learning like 20 days after starting to learn that language, I did my first big project which was a bot reader for Counter Strike. Like, who plays Counter Strike here? Yeah, so if you play the multiplayer mode, then you have an option to play against bots. So, you can play locally with bots. So, this bot reader, what it did was it allowed you to edit bot profiles. So, after that, after I think two months from that, I developed another clipboard manager software called ClipJob which I continued developing for three plus years. Like, I left it in 2016 when I switched to Linux because Autohorkey is only available on Windows. So, meanwhile, I also developed a lot of Autohorkey libraries and scripts. So, I would like to thank, give my thanks to the Autohorkey community because it bring out the developer in me. If there would have been no Autohorkey, I wouldn't have started coding. So, thank you Autohorkey. And I also started to do some competitive programming by 2014 on Corsair for Hackerank. So, before 2014, I only knew Autohorkey and as you know, it is on Windows and Windows like open source, users like don't love Windows a lot. So, GSOC has no place for Windows Autohorkey. Therefore, I was able to participate in GSOC 2015. So, I started to learn Python by 2015 and by 2016, I was confident enough to like drag GSOC under fossils here. GSOC 2016 was a very memorable period of my life. Very memorable period of my life. And after that, I actually mentored young students under Google code in. So, that too was a great experience. Like being able to boss other people around is a great experience. So, after that, right now, I am working at a contract developer at AppBase.io. It's a company that deals with Elasticsearch clusters. And it provides a real-time API to work with Elasticsearch. So, about my strengths, about my skills, I mainly do backend development and I also have an anode degree in Android which was sponsored by Google. And I like scripting, I like web scraping. So, my journey with FOSS Asia started through GSOC 2016. So, I was actually looking at an organization's list and there was this huge list of organizations. Big names like Drupal, Zoomla, PSF, CodeOS. So, I was like very scared. But then, I saw FOSS Asia and there was ACR written in it. So, maybe I thought they will have some reservation for ACLs. So, I looked into it and I saw that open event of our project. It was in Python Flash. I knew a bit about it. So, I tried to understand the code base and I was able to figure it out and contribute to it. So, I was selected to FOSS Asia and it successfully qualified GSOC 2016. The great thing about FOSS Asia I think is that it has a very friendly and open community. Like anyone who wants to be a part of it can be a part of it. There are a lot of other organizations like... I won't take the name but they have huge set of rules to actually be a part of them. You have to be like, what do you say, evolved by someone else to become a part of that. So, those types of things don't exist in FOSS Asia. If you want to take a be a part of FOSS Asia, you can just open an issue world. Directly talk to the head next morning, Mario, and he will add you to the team. So, back to the topic. What is open event project? So, I will give a very brief overview on the open event project. Like tech events and conferences are very important for the developer community. When you come to a tech event or a conference, you get to know other people, you get to learn about new technologies, trending technologies and you can enhance your network. So, these type of things, if you're working alone or if you're working in a limited company, you won't be able to access these things. So, this is the importance for that tech conferences. So, right now if you look at tools that are available to manage tech conferences or in general conferences and events, then we have event private meetups, those type of things, and these things are proprietary, they are not open source, they are not hackable, they are not customizable. So, we actually created a very good, we created a good versatile tool to manage these type of events. I think like Mario had the idea in 2015 or 2014 maybe. And so, we started the project open event. So, I'm going to speak about open event API. So, yeah, what's an API? So, API is a way for apps to interact with the server. Like you have a server running at some place remote in West region USA. So, you have an app here and you want the app to test data from the server. So, API provides a language, API is like a language in which a server talks to a user. So, as you know that every language has a fixed syntax, you can't just speak anything in a language. So, same API has a fixed syntax, the server and the user both knows that language and when they want to talk to each other, they use that language. So, here's a diagram that shows how API, here's like a flow chart showing how the API works. So, at the left side you will see we have the application data model which is actually the server part and it will show how the data is stored in the database. So, API provides an interface to access that data. So, here if you see you have that entry point, inside entry point you have collection, inside collection you have resource. So, it's like a hierarchy level. So, entry point could be like slash API then collection could be slash events and resource could be slash tickets. So, inside API you have event, inside event you have tickets. So, this is how it goes. And the client actually uses an STT library or maybe if it's like sophisticated it will use a REST library to access the API. So, and the data that flows between the API and between the server and the client actually follows some schema. Here is the sample very limited schema showing how an API response looks like. As you may know this is in JSON format. So, the data is, you can see that the first value success is true which can be used as a way to tell that everything that works, the process under the API was successful. Then we have the data packet which shows the different type of data that API returned and we have the error set as a means that there was no error in processing the request. So, API has other concepts like status codes. So, what is status codes is that like suppose API can return different type of error, different type of messages. So, suppose the request was successful it will return a different message and suppose if request failed, suppose this type, suppose that the user was not authenticated, not privileged to access that request then their request failed. So, for that it will use, it will have to return a different type of message. So, you can't just write like, I will take an example of traffic light. So, traffic light uses red light, yellow light and green light. So, red light shows that you will have to stop, yellow light shows that the light is going to turn green soon so be ready and green shows that you are ready to go. So, right now why the system is like that? Why can't it be like, here you should stop, write a sentence or here you should wait, here you should go. So, it is because that people would conceive the meaning differently if we use like English sentences or English language. But if we use symbols or like fixed codes then the meaning is like universal, everyone can relate to it, everyone can understand it. So, there is where status codes come into play and for error request we usually have 200 status code and for error request we have 300, 400 or 500, 300 like 301, 302, 401, 402 400 or 500 something request. And response type is the type in which an API returns a response. Most common response type is JSON which you can see here but we also, some people also use XML. I don't know what's the advantage of that and then we have headers in the API. So, what are headers is that suppose you are returning a data in an API but the data needs to be consistent like it should relate to the request which was asked. So, headers provides additional information that should be returned with a request. One more advantage of header is that suppose the server changes in some way that it needs to provide additional data to the client. So, it can attach that information to the header instead of changing the body which is this. So, the client app won't have to be updated again to actually actually understand this material. So, you might understand now that why API is needed. So, API is like a bridge that connects the backend server to the rest of the world. If we don't have an API then the server is like running isolated somewhere in the USA and client apps are running everywhere but they don't have any information. API can be used by both Android apps as well as websites almost everything that's not on the same computer as server will use the API to access information from the server. So, API is the curtain drain of the open event for them. Like you know that API open event is very expensive. We have app generators, we have web app generators, we have websites. These components all depend on a central server for the data. So, API provides a way for these apps, these client apps to access the data from the server. A little about the code base before we begin. The code base of the server part has been written in Python Python 2 and it uses the flash framework. Database is handled through SQL alchemy and migration is managed through LNBIG. I would like to tell something about LNBIG here. So, why we use migration is that suppose that one person is running the server code base which is of 28th January. Now suppose that database was updated on 29th January and now the person wants to run the code from 29th January. So, if he runs that code again, then the code will access a non-existing field database which was not created on 28th January. So, for that we actually use LNBIG. So, LNBIG will track the changes in the database and it will it will create a separate file for that. So, if you then if you you can pass that file to the existing database and so the database will be updated according to the new changes. So, like you know, Git is a virtual control system. LNBIG is a virtual control system for databases. So, before we start beginning the development of the API, we had to choose a framework. Like it was going to be a big project, big work. So, we can't just like go blindly. We have to carefully consider how to how we are going to code that. So, we thought that the API framework that we are supposed to use should be modular, should be hackable and should allow document generation. So, modular because lots of people, I remember that six people were working concurrently on the server project in GSOC last year. So, if six people are working, so one can change one file and another can change another file. So, we don't want conflicts. So, for that we needed a modular framework. So, modular framework will allow us to develop one API in one file and another API in another file. So, we had to choose a modular framework. Next hackable and hackable because we were doing we were making the a very specific use case of the API. So, we wanted to be sure that every of our needs will be covered by the framework. Like, suppose not every framework does everything. Some framework may not support authentication, some framework may not support input validation. So, if that's the case, we want that a framework should allow us to hack into it and add that feature. And third was that it should provide ease of documentation generation. So, six people working on a project every day for like three months and concurrent projects like the Android app and the website was going on. So, we wanted that the documentation of the API should be up to date, as up to date as possible. Like, if one commit is merged to master then the documentation should be generated in like quickly so that the developers working on the client app should know what the changes are and what the changes they are supposed to do. So, we needed a framework that would allow us to do this automatically. So, the framework candidates were Flask API, Flask REST Plus, Flask REST Full. We were also thinking about using like no framework at all. Python, Flask already provides a way to interact, like handle API responses. But in that case, we will have to do a lot of work manually. So, Flask API was a very limited framework. We had to make a decision between Flask REST Plus and Flask REST Full. So, Flask REST Full is a very powerful framework but it doesn't provide automatic documentation in recent feature. Flask REST Plus provides that feature so we settled for Flask REST Plus. So, why did we choose Flask REST Plus? First, it provided the ability to write modular code. So, that allowed us to write like I was doing the event API and Irelian would do the session API concurrently. So, that was the reason we used Flask REST Plus. Session API was in a different file and event API was in a different Python file. And Flask REST Plus allowed us to define response models clearly. Like if you want to return a response from a code then you can just create a JSON, hard code a JSON and just return it. But that is not a good way to do especially when you are working in a team. When six or ten people are working together you don't want that other guy to be clueless but he has done. So, with Flask REST Plus we were able to define the response models clearly and Flask REST Plus also like automatically generated a documentation. That was a big plus for us. It provided group ints and it was hackable. Like we hacked it to add custom API request input validation custom error. These type of features were very important. Custom API request allowed us to do different types, add different type of request that a server would do and input validation allowed us to check for errors in the input data when server got that data and then we implemented errors also. So the code looks like this. First we have the app folder, inside app folder we have a whole of the code. API resides in the API folder. We have help first folder, models folder for the base tables. We have static folder for static data like images or logos. We have templates folder for the HTML view and then we have views folder for interacting with the website. So defining an API in Flask REST Plus is actually very easy. First you create a namespace, then a model, then a resource and then you attach namespace to API. I will show an example for this. So here you can see it's a working code. This code actually works and will allow you to create a server with an API already. So at first we import Flask and Flask REST Plus which is the library that we are using. We create a Flask app, we add, we create an API for the app and then we create a namespace. So namespace, as you can see here, we are using the string events which means that this API will be created at Flask events. So suppose we wanted to create a sessions API we can use namespace, namespace, course, sessions, description equal to sessions. So that would have created a sessions API but for this example I am using events, so events API and we attach the namespace to the API here in this line and now we create a resource. So what's our resource? Resource is actually a URL that a server that an API works through. Resource is a URL that from where an API works through. So I have added a Slash here which means that this API will be accessible through Slash events Slash and now I have defined two methods here get and post. So what get means is suppose someone sends a get request to that URL then this message will be returned and if someone sends a post method to that URL then this code will run. So like this you can define delete and you can define put here which will be corresponding for ring operation and update operation. So these are the open event API endpoints that we have in the open event project. First is the events API which allows you to deal with events like suppose you want to create an event, you want to update an event, you want to delete an event, you want to get list of events or get a single event, you can use the event API. Then we have a sessions API which will allow you to get individual sessions or add a session to an event, those types of things. Similarly we have try APIs, speakers, sponsors, micro locations, login and users. So let me talk about the swagger documentation. So as I was already telling auto generating the documentation was a very important factor for choosing the REST framework. So the auto generation of the documentation was done by following the swagger specification. So if you are using open event project and you have deployed to your server then you can access the docs for the API at server slash api slash v1. This is the URL. Suppose that event is hosted on event.com so if you want to access the API documentation you can go to event.com slash api slash v1. So this is how this URL looks like. So here you can see the list of all the namespaces which I mentioned here. So we have the events API, sessions API, tracks, speakers and everything. And if you click on an API here you will see all the endpoints that are available inside the API. Here I click on the tracks API and I can see get API and get the method to get list all tracks the method to create a track, the method to list tracks in a paginated manner means in a piece like manner and I can see a method to delete a track when we have REST ID and we can also fetch a track if we know it's ID and we can also update a track. So if you create on one of these endpoints here then you can see how the response value will look like and if you click on one of the endpoints here you can see how the response value will look like. Like suppose if I query this URL using a get request I will get this response which will contain the sessions inside the track which will contain the location of the track which will contain the color of the track and the ID of the track. Now suppose if I click on a post request here so this shows the response that I will get and also the input that I have to send to the as a post request. Like here you see event ID included in curly braces it means that it is a variable. So you will substitute event ID with a number which is the ID of the event. So I will add the event ID here I will add the data to be sent here like this is creating a track so if I add track name like track credentials like track name, location, and add it here and click on the post button then it will then a track will be created. So all of this was created from from this codebase. You write a simple codebase like this and you will have that this website created with this dynamic website created with all the javascript and listing and this response models. So how does this work? So the main reason why this works is because you are following certain conventions like you are defining the input and output models clearly so input model was here like here we have this is the input model here so I have defined the event input model which shows me the data type and the API should accept into it and I have defined the output model here which shows me the response type that the API will give out to the rest of the world and I have defined resource and models. So let's see this code this is the input model, the output model and this is the resource which is actually the API endpoint I have defined the get method and the post method. Now when I run this code that website is created with the get request and the port request documentation. So Flasters Plus already provides more documentation parameters like .doc, .params, .response and .headers for .doc what you can do is .doc allows you to create an ID for an API .params allows you to add query parameters to the documentation like suppose you have a URL which accepts query parameters. Query parameters are those parameters like if you add a question mark and then it is equal to something and x equal to something those type of things are called query parameters. So you can specify that in the documentation as well you can specify this response codes like 200, response code 400, 500 and if you specify headers in the documentation as well so API authentication so API authentication is open event is like very versatile like one of the very common methods for API authentication is called basic authentication in which what we do is we add the username and the password to the header and we send it as a request similarly we have the JWT in which you get a token and you will add a token to the header and send it as a request and we can also use session with authentication in which a cookie is set on the server and you use that. So this is a code that shows how authentication looks like I will just skip it for now as I am running low on time so let's talk about the import and export feature so so import and export feature of the open event is what makes it truly open so using the import and export feature what you can do is like you are having an event on eventEAE.com and suppose you now want to host it on your own site so you can export the event from eventEAE.com and you can import it back in your own site like that if eventEAE.com even goes down or disappears from the internet you will still have your event so that is why import and export feature is so cool so it will allow you to have an event template and it will give you a full backup of your event and it can allow you to archive old events like you have an event from 2027 and you want to archive it so you can use that import feature so what open event can do is it will allow you to manage your event like if you want to have call for call for speakers or tickets you can do it with open event you can create an app for an event you can create a website for an event and all of this comes for free so that's the power of open event know the technology eventEAE.com event comes close to that so this is how the export file looks like it contains all the data that an event has and it is organized by folders so we are also using like background tasks like suppose you are supposed to send up sorry I will finish yeah let me just conclude it so actually in last gsoft me and sivam manguin he is not here right now but we work on the api part of the open event project if you want to know more about api part you can visit our blog links so you can actually remember this very easily like is.good slash open event api blog 1 is.good slash open event api blog 2 and if you have got any questions you can ask me or you can pick me on twitter thank you