WEBVTT 00:00.120 --> 00:01.710 Hello everyone and welcome back. 00:02.190 --> 00:06.160 So let's start with a very important question. 00:06.180 --> 00:10.430 This is in fact one of the most important questions of the entire course. 00:10.470 --> 00:19.620 What is an EPA EPA stands for application programming interface and in general terms in EPA is a set 00:19.620 --> 00:27.000 of clearly defined methods of communication between different software components a good EPA makes it 00:27.000 --> 00:33.150 easier to develop software by providing all the building blocks which are then put together by developers 00:33.600 --> 00:40.260 as a matter of fact an API declares an interface that allows us to interact with its logic without having 00:40.260 --> 00:47.520 to know what happens as the saying goes under the hood and API eyes are everywhere really operating 00:47.520 --> 00:51.420 systems programs programming languages and software libraries. 00:51.480 --> 00:55.220 The Web of course computer hardware and so on. 00:55.260 --> 01:00.300 Therefore there are different kinds of API in this course. 01:00.300 --> 01:07.890 We're going to talk about web API as you can think about web API is as a set of protocols for communication 01:08.070 --> 01:14.400 between either different web applications or different parts of the same application and that allow 01:14.400 --> 01:22.410 external clients such as for example a smartphone app to connect and communicate with our web app. 01:22.450 --> 01:28.650 Do most common kind of web API nowadays is addressed in the API is that will go into building this course 01:28.870 --> 01:30.960 are going to be REST API. 01:31.080 --> 01:35.670 Or as some developers like to call them RESTful API. 01:35.820 --> 01:39.500 We will talk about the rest and its features in the next lesson. 01:39.510 --> 01:44.210 Now it's very important to answer the following questions first. 01:44.460 --> 01:48.250 Why would we want to develop an API in the first place. 01:48.300 --> 01:50.570 What our API is really useful for. 01:51.270 --> 01:56.790 Well let's take as example two very important companies like Instagram and Twitter. 01:57.060 --> 01:59.330 They both have an official Web site. 01:59.430 --> 02:05.310 You can access from the browser of course and they also provide applications for smartphones with different 02:05.310 --> 02:13.530 operating systems such as Android in us in each one of these applications is access to the same synchronized 02:13.620 --> 02:16.820 contents without a web API. 02:16.860 --> 02:23.250 A basic architecture for a similar web service may look like the one shown in this diagram. 02:23.250 --> 02:26.820 Each client app has its own embedded business logic. 02:26.820 --> 02:32.520 Most likely written we have a specific programming language connecting them directly to the database 02:32.760 --> 02:35.290 to get and manipulate data. 02:35.460 --> 02:42.720 Maintaining is killing a Web service that uses such an architecture could easily become very challenging. 02:42.720 --> 02:46.870 As for each new feature you might want to add to your web service. 02:46.870 --> 02:50.130 You'd have to update each up accordingly Of course. 02:50.130 --> 02:53.070 And this can be a very expensive event. 02:53.070 --> 03:00.690 Error prone process which often leads to bugs feature fragmentation and overall project delays which 03:00.690 --> 03:02.550 we never want to have. 03:02.580 --> 03:07.240 API is allow us to build a much more powerful architecture instead. 03:07.350 --> 03:08.470 Let's have a look. 03:08.760 --> 03:15.700 Using an API first approach to development process gets much easier and faster. 03:15.750 --> 03:23.670 The API provides a common interface that can be used by all the client applications to interact with 03:23.670 --> 03:28.740 its own business logic so that each app as feature parity. 03:28.740 --> 03:34.920 And if you need to implement a new feature or maybe an update you just make it in one place. 03:34.920 --> 03:40.500 The apps itself will then simply become the user interface layer of a service we're providing to our 03:40.500 --> 03:41.630 users. 03:41.910 --> 03:48.000 With such an architecture it's important for the different parts of our application to communicate with 03:48.000 --> 03:55.500 each other using a standard file format that should be both human readable and fast for computers to 03:55.500 --> 03:56.320 process. 03:56.550 --> 04:04.890 One of the most common file formats used by API is is Jason where Jason stands for JavaScript object 04:04.980 --> 04:13.520 notation and the Jason object is a lease to a set of key value pairs surrounded by curly braces. 04:13.590 --> 04:20.820 So this is an example of a scene pulling she's on object for a service slide could be Twitter for example. 04:20.820 --> 04:29.070 As we've mentioned it's a set of key value pairs surrounded by curly braces and of course as we can 04:29.070 --> 04:35.520 see this is both human readable and pretty fast for computers to process because let's say that our 04:35.520 --> 04:39.530 front end client needs to show the creation date for. 04:39.540 --> 04:41.690 That could be like a tweet object. 04:41.690 --> 04:42.170 Okay. 04:42.240 --> 04:49.500 It can just reference the creator dead key to know the exact date of creation of our tweet and as we 04:49.500 --> 04:56.610 can see in this specific example that we are using strings each key is assigned to a string. 04:56.700 --> 05:04.000 But if we need to of course we can use the structure the data types like for example lists. 05:04.120 --> 05:10.780 So in this example that we see dead to make it easier for our client and overall to make our application 05:10.780 --> 05:11.950 more performance. 05:11.980 --> 05:20.500 OK we are using a new key aspects that we've assigned to an array at least of the ash stacks used on 05:20.500 --> 05:22.170 the same tweet object. 05:22.270 --> 05:24.890 And if we want to we can even get more advanced. 05:24.940 --> 05:31.690 For example we see adjacent object nested weaving analogies an object so that for example if I needed 05:31.690 --> 05:38.050 to know the location of the specific user that is written that specific tweet instance. 05:38.230 --> 05:44.830 I would just have to reference user content of course location to noise without having to make another 05:44.830 --> 05:46.540 request to our arrest API. 05:46.630 --> 05:54.790 OK now that we've got an idea of what a way BPI is and what file format to use we rebid we might ask 05:54.790 --> 06:00.390 ourselves how can we get access and interact with the API. 06:00.430 --> 06:06.720 What sort of channel or access point should we use we can access our API is using this so-called end 06:06.730 --> 06:07.690 points. 06:07.690 --> 06:14.800 Typically you add real partners that we can use to specify what path equal information or service we 06:14.800 --> 06:16.270 want to access. 06:16.420 --> 06:19.740 Using the 5 format that are used by the API. 06:19.990 --> 06:24.200 So for instance going to select tweets could give us an API. 06:24.200 --> 06:30.670 Jason response containing at least with all the tweets of for example our tweets feed at a particular 06:30.670 --> 06:32.610 moment in time in the system. 06:32.650 --> 06:41.650 OK we might go to his left tweets as Lesh a primary key like 5 3 6 7 2 3 for example to grab the details 06:41.680 --> 06:43.900 of a specific instance. 06:43.900 --> 06:51.550 We could also go to his left tweets slash and the same primary key slash Ash text slash to get maybe 06:51.550 --> 06:56.300 a list of all the ash tags of that same tweet object saving. 06:56.470 --> 07:03.430 We could do for the details of the user that owns that tweet instance in the next lecture we're going 07:03.430 --> 07:09.490 to continue our discussion about API is getting to the details of the technical implementation of a 07:09.490 --> 07:16.300 specific kind of API that we are going to build throughout the course as we said rest api is this will 07:16.300 --> 07:24.550 also give us the opportunity to talk about two very important related topics HDTV and status codes so 07:24.640 --> 07:26.020 see you in the next lecture.