WEBVTT

1
00:00.000 --> 00:05.280
Alrighty friends, we are slowly demystifying APIs. Let's talk about the most

2
00:05.280 --> 00:06.720
common architectural style

3
00:06.720 --> 00:11.980
and this is the REST API. Now notice the actual terminology I happen to use it.

4
00:11.980 --> 00:12.560
I mentioned this

5
00:12.560 --> 00:17.380
was an architectural style. This is really what we're talking about. REST is a

6
00:17.380 --> 00:18.960
type of architecture.

7
00:18.960 --> 00:23.710
So let's talk about how this particular API style is implemented then, okay?

8
00:23.710 --> 00:24.320
Now the first thing to

9
00:24.320 --> 00:29.630
state is that REST APIs are super, super common in the world of web services

10
00:29.630 --> 00:30.880
and the way the REST
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

10
00:29.630 --> 00:30.880
and the way the REST

11
00:30.880 --> 00:37.000
API happens to operate is utilizing what is known as a client server model. So

12
00:37.000 --> 00:38.080
the server is pretty much

13
00:38.080 --> 00:42.650
where the data is actually stored and the client is the one making requests to

14
00:42.650 --> 00:44.320
that particular server.

15
00:44.320 --> 00:48.460
So let's just draw out for a bit, okay? Here is our server over here and over

16
00:48.460 --> 00:49.360
here this can be your

17
00:49.360 --> 00:52.870
client. This is just me on my laptop, let's just say, okay? So let's imagine

18
00:52.870 --> 00:54.160
that the type of API

19
00:54.160 --> 00:58.370
available is a REST API. So essentially I as the client want to make a

20
00:58.370 --> 00:59.600
connection with this

21
00:59.600 --> 01:05.600
particular server and the transport that I'm going to use is going to be HTTP
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

21
00:59.600 --> 01:05.600
particular server and the transport that I'm going to use is going to be HTTP

22
01:05.600 --> 01:07.120
or more specifically

23
01:07.120 --> 01:11.910
what you really want to be using is HTTPS which is the secure version utilizing

24
01:11.910 --> 01:12.960
encryption.

25
01:12.960 --> 01:17.440
Now one thing to state about our actual requests is that the requests happen to

26
01:17.440 --> 01:18.640
be what are known as

27
01:18.640 --> 01:23.040
stateless. So what does stateless actually mean in this particular context?

28
01:23.040 --> 01:24.560
What I'm talking about

29
01:24.560 --> 01:29.070
is that the server and the client do not have to remember anything about any

30
01:29.070 --> 01:30.240
previous requests.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

30
01:29.070 --> 01:30.240
previous requests.

31
01:30.240 --> 01:34.640
So let's imagine this was request number one and then after we want to make a

32
01:34.640 --> 01:35.680
second request,

33
01:35.680 --> 01:40.240
now the success or failure of this particular request has nothing to do with

34
01:40.240 --> 01:41.200
the previous request

35
01:41.200 --> 01:45.100
that came before it. We don't have to remember the information each individual

36
01:45.100 --> 01:46.080
request is going to be

37
01:46.080 --> 01:50.500
evaluated on its own merit. Has the request been formatted correctly? Is it

38
01:50.500 --> 01:51.520
requesting valid

39
01:51.520 --> 01:55.480
information? Do we have permission to get the information so on so forth? So

40
01:55.480 --> 01:56.400
long as we actually

41
01:56.400 --> 02:00.400
pass all that criteria, then each message on their own is going to return a
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

41
01:56.400 --> 02:00.400
pass all that criteria, then each message on their own is going to return a

42
02:00.400 --> 02:01.760
successful response.

43
02:01.760 --> 02:05.700
Now I just mentioned the fact that we are utilizing HTTP, the hypertext

44
02:05.700 --> 02:07.280
transfer protocol to

45
02:07.280 --> 02:11.630
transport our information or to transport our request and facilitate the

46
02:11.630 --> 02:12.560
responses. And this

47
02:12.560 --> 02:15.940
is actually pretty handy because what we actually do is we make use of what are

48
02:15.940 --> 02:17.680
known as HTTP

49
02:17.680 --> 02:21.260
methods and we'll talk about these in a little bit more detail in the upcoming

50
02:21.260 --> 02:22.400
video. But ultimately,

51
02:22.400 --> 02:26.960
these methods allow us to specify the type of communication that we are

52
02:26.960 --> 02:28.480
creating or the type of

53
02:28.480 --> 02:31.730
information we are requesting that type of thing. Okay, so what type of
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

53
02:28.480 --> 02:31.730
information we are requesting that type of thing. Okay, so what type of

54
02:31.730 --> 02:32.880
requests are we actually

55
02:32.880 --> 02:37.750
talking about here? Well, as you can imagine, that completely depends on your

56
02:37.750 --> 02:38.640
intent. Let's

57
02:38.640 --> 02:42.240
maybe say that the server over here happens to be storing some really

58
02:42.240 --> 02:43.600
interesting information

59
02:43.600 --> 02:49.010
about the vacation destinations such as the Bahamas. Well, in that case, what

60
02:49.010 --> 02:49.760
you might want to be

61
02:49.760 --> 02:53.800
doing is just simply reading the information from that particular server. Okay,

62
02:53.800 --> 02:54.560
we're not trying to

63
02:54.560 --> 02:58.710
modify anything. We just want to ask what information do you have? Send it back

64
02:58.710 --> 02:59.680
to me, please. And

65
02:59.680 --> 03:03.420
actually going to see that actually is a very particular HTTP method to perform
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

65
02:59.680 --> 03:03.420
actually going to see that actually is a very particular HTTP method to perform

66
03:03.420 --> 03:04.320
that action.

67
03:04.320 --> 03:09.750
Whereas, maybe you would like to insert new information into the server itself.

68
03:09.750 --> 03:10.240
I don't know,

69
03:10.240 --> 03:13.670
let's maybe say you wanted to create a booking on this particular server so

70
03:13.670 --> 03:15.040
that server was storing

71
03:15.040 --> 03:19.410
your details such as when you want to go. The fact that you have paid your

72
03:19.410 --> 03:20.400
money, what your name

73
03:20.400 --> 03:23.940
measure age is that type of thing. Well, that is a completely different

74
03:23.940 --> 03:25.280
operation that you can

75
03:25.280 --> 03:29.970
once again specify with a very particular HTTP method. Similarly, maybe you

76
03:29.970 --> 03:31.520
want to perhaps update
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

76
03:29.970 --> 03:31.520
want to perhaps update

77
03:31.520 --> 03:35.960
existing information that already exists on the server. Maybe just use a little

78
03:35.960 --> 03:36.720
modification that

79
03:36.720 --> 03:41.200
is another way you can do that via another HTTP method. And similar, let's

80
03:41.200 --> 03:42.400
maybe say you wanted to

81
03:42.400 --> 03:45.920
perhaps know that it's delete information from the server. Then you guessed

82
03:45.920 --> 03:46.720
that once again,

83
03:46.720 --> 03:50.350
we do actually have a particular method to perform this action. Now in a

84
03:50.350 --> 03:51.200
similar way with

85
03:51.200 --> 03:54.800
rest APIs, we're also going to make use of something known as headers. Again,

86
03:54.800 --> 03:55.600
we'll talk about this

87
03:55.600 --> 03:58.730
in a little bit more detail very, very shortly. Now these headers ultimately

88
03:58.730 --> 03:59.920
allow to specify the

89
03:59.920 --> 04:04.220
type of information that we are wanting to receive or perhaps specifying the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

89
03:59.920 --> 04:04.220
type of information that we are wanting to receive or perhaps specifying the

90
04:04.220 --> 04:05.280
type of information we

91
04:05.280 --> 04:09.120
want to be sending. So let's maybe say we want to make a request to the server

92
04:09.120 --> 04:10.160
and we want to

93
04:10.160 --> 04:15.440
receive the information back formatted in JSON. We can essentially utilize our

94
04:15.440 --> 04:16.960
headers to specify

95
04:16.960 --> 04:21.430
that particular preference. Similar to let's maybe say we want to be updating a

96
04:21.430 --> 04:22.320
server. And for

97
04:22.320 --> 04:26.430
whatever reason, we're going to be using some type of XML based payload, well,

98
04:26.430 --> 04:27.440
we can specify to

99
04:27.440 --> 04:32.090
the server that we're going to be sending XML type data. Okay, so we know that
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

99
04:27.440 --> 04:32.090
the server that we're going to be sending XML type data. Okay, so we know that

100
04:32.090 --> 04:32.960
rest is going to be

101
04:32.960 --> 04:38.730
utilizing HTTP or HTTPS. We have HTTP methods that we can use to specify the

102
04:38.730 --> 04:40.000
type of operation that we

103
04:40.000 --> 04:43.490
want to use. Are we getting information? Are we deleting information? That type

104
04:43.490 --> 04:44.320
of thing? We have

105
04:44.320 --> 04:48.070
these headers to specify the type of information we want or the type of

106
04:48.070 --> 04:49.760
information we want to send.

107
04:49.760 --> 04:54.490
All of these well integrated into the rest architecture, but perhaps the most,

108
04:54.490 --> 04:54.880
well, I don't want

109
04:54.880 --> 04:58.660
to say the most important one because they're all very, very important, but one

110
04:58.660 --> 04:59.920
real core fundamental

111
04:59.920 --> 05:05.010
thing with respect to rest APIs is the understanding that you arise. These
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

111
04:59.920 --> 05:05.010
thing with respect to rest APIs is the understanding that you arise. These

112
05:05.010 --> 05:06.800
actually point to very

113
05:06.800 --> 05:11.160
particular resources. Now what an earth am I talking about? Let me show you

114
05:11.160 --> 05:12.480
what I mean here. Okay,

115
05:12.480 --> 05:17.360
here I am on my browser right here. And let's maybe say I wanted to access the

116
05:17.360 --> 05:18.800
CBT Nuggets server.

117
05:18.800 --> 05:22.900
Well, what I can do is enter CBT Nuggets.com and as we can see here, this

118
05:22.900 --> 05:24.400
actually takes me to the

119
05:24.400 --> 05:28.860
CBT Nuggets homepage. Now let's maybe say I wanted to access a very particular

120
05:28.860 --> 05:30.320
resource on the server
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

120
05:28.860 --> 05:30.320
resource on the server

121
05:30.320 --> 05:35.080
itself. What would I actually do? If I modify my URL request, that is going to

122
05:35.080 --> 05:36.720
correlate to a different

123
05:36.720 --> 05:40.400
resource on the server and serve up a different page to me. So say, for example

124
05:40.400 --> 05:41.520
, once again, if I just

125
05:41.520 --> 05:46.660
zoom in a little bit, if I modify the URL to be forward slash blog and now hit

126
05:46.660 --> 05:47.760
enter, look at this

127
05:47.760 --> 05:51.690
right here. We actually get a different resource on the CBT Nuggets server. Now

128
05:51.690 --> 05:52.480
we're getting the

129
05:52.480 --> 05:56.870
blog information. See that correlation? The actual URL path actually pulls a

130
05:56.870 --> 05:58.080
different piece of

131
05:58.080 --> 06:01.340
information from the server itself. Now this is basically what I'm talking
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

131
05:58.080 --> 06:01.340
information from the server itself. Now this is basically what I'm talking

132
06:01.340 --> 06:02.560
about with respect to

133
06:02.560 --> 06:07.950
REST APIs. Let's imagine you've got a Cisco WebEx application. Okay, now Cisco

134
06:07.950 --> 06:09.120
WebEx is basically

135
06:09.120 --> 06:13.740
just Cisco's collaboration platform for being able to send messages, create

136
06:13.740 --> 06:14.640
chat channels,

137
06:14.640 --> 06:19.290
video meetings, that type of thing. But Cisco WebEx also has a REST API. Okay,

138
06:19.290 --> 06:20.080
so let's imagine

139
06:20.080 --> 06:24.130
me over here on my little laptop and also let's say, for example, it had a

140
06:24.130 --> 06:25.360
little home network here.

141
06:25.360 --> 06:31.330
These can be three routers all connected. Okay, R1, R2 and R3. Now suppose, for
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

141
06:25.360 --> 06:31.330
These can be three routers all connected. Okay, R1, R2 and R3. Now suppose, for

142
06:31.330 --> 06:32.640
example, I was using my

143
06:32.640 --> 06:36.810
Python script to effectively go out to my network, connect to all my devices

144
06:36.810 --> 06:38.000
and run some particular

145
06:38.000 --> 06:42.340
tests. Let's imagine that I was testing that all my OSPF adjacencies were in

146
06:42.340 --> 06:43.280
the full state.

147
06:43.280 --> 06:48.870
And every time I ran this script, I wanted to send a message into Cisco WebEx

148
06:48.870 --> 06:49.440
so that everyone

149
06:49.440 --> 06:54.080
using the chat channel could ultimately see the result of this particular test.

150
06:54.080 --> 06:54.960
Well, my Python

151
06:54.960 --> 06:59.220
script, after running this particular test against my network, would then have

152
06:59.220 --> 07:00.720
to craft an HTTP
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

152
06:59.220 --> 07:00.720
to craft an HTTP

153
07:00.720 --> 07:06.440
request, or HTTPS should I say, to the WebEx REST API. Now the crucial thing

154
07:06.440 --> 07:07.920
here is if I want to

155
07:07.920 --> 07:12.400
access a particular resource on this particular server, say, for example, I

156
07:12.400 --> 07:13.680
want to be able to,

157
07:13.680 --> 07:17.820
oh, I don't know, let's maybe say I wanted to send a message programmatically.

158
07:17.820 --> 07:18.640
Then this particular

159
07:18.640 --> 07:22.310
functionality, the ability to send a message will actually correlate to a

160
07:22.310 --> 07:23.360
particular URL.

161
07:23.360 --> 07:26.640
Now what you would do before actually writing the Python script is you would go

162
07:26.640 --> 07:27.520
to say, for example,

163
07:27.520 --> 07:32.240
the WebEx documentation, find out about its REST API, and then find out, hey,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

163
07:27.520 --> 07:32.240
the WebEx documentation, find out about its REST API, and then find out, hey,

164
07:32.240 --> 07:33.600
if I want to send a

165
07:33.600 --> 07:37.270
message, which URL would I have to use in order to be able to send that message

166
07:37.270 --> 07:38.160
? So let me show you

167
07:38.160 --> 07:42.480
what I mean once again. If you search for WebEx REST API, let's click this here

168
07:42.480 --> 07:43.360
. Now if you get in

169
07:43.360 --> 07:46.990
the left hand side, we can see the full API reference. So if I just scroll to

170
07:46.990 --> 07:48.160
the documentation and

171
07:48.160 --> 07:52.690
find the page for messages, which we can see right here, let's click this. What

172
07:52.690 --> 07:53.520
it actually tells me

173
07:53.520 --> 07:57.630
here is the actual URLs I would have to use in order to be able to, you know,

174
07:57.630 --> 07:58.960
either list the messages

175
07:58.960 --> 08:02.630
I've already created or create a brand new message, that type of thing. So in
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

175
07:58.960 --> 08:02.630
I've already created or create a brand new message, that type of thing. So in

176
08:02.630 --> 08:03.840
my case here, I would use

177
08:03.840 --> 08:08.450
this particular URL and then I could create a message resource on the actual

178
08:08.450 --> 08:10.000
server itself. Whereas,

179
08:10.000 --> 08:14.100
say, for example, I wanted to create a brand new room utilizing Python. We can

180
08:14.100 --> 08:15.120
indeed see here that

181
08:15.120 --> 08:18.620
to create a room, the actual endpoints here are completely different. This one

182
08:18.620 --> 08:20.480
here is forward/rooms

183
08:20.480 --> 08:25.100
as opposed to forward/messages. This is how we determine what it is we want to

184
08:25.100 --> 08:26.080
do on the server.

185
08:26.080 --> 08:30.080
So now we are beginning to tease out more information about how REST APIs
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

185
08:26.080 --> 08:30.080
So now we are beginning to tease out more information about how REST APIs

186
08:30.080 --> 08:31.840
actually operate. Let's now take

187
08:31.840 --> 08:35.520
a little bit more time talking about these HTTP methods.