Now there's some theory with regards to rest.
I'm going to quickly go through it now.
Don't get hung up about the theory.
Jump to the next video if the theory is a bit boring.
You're going to learn more.
If I show you the stuff practically I've given you.
This PowerPoint slide contains some useful information.
So download that if you want to for reading later or for studying, but you're going to learn much more
if you just do it, don't read about it.
If you do it, practically the stuff will make sense.
So if you find this boring, please go to the next video.
Do it practically.
And then you can come back to the theory.
Now the first question is what is rest?
And a great place to look for good information is restful API dot net and we're told that rest is a
acronym for representational state transfer.
It's an architectural style for distributed hyper media systems that was first presented by Roy Fielding
in 2000 in his famous dissertation.
And they've got a link to his dissertation and you can read this whole dissertation to get an idea of
what it's about.
He talks about the fact that it's client server, that it's stateless.
Caching you supported and a whole bunch of other detailed information.
So if you really want to get into it, you can have a look at this.
But let's just summarize it.
I want to go through this fairly quickly and actually show you practically how it works because you'll
learn a lot more if you see it practically rather than just looking at some theory.
First thing is its client server.
By separating the user interface concerns from the data storage concerns.
We improve the portability of the user interface across multiple platforms.
It's basically a client talking to a server.
So I've got a PC talking to a server.
Client server model similar to what we do with HTTP.
I want to go to facebook.com or some kind of web server.
I've got a client running on my computer here, Mac, and I'm connecting to the server.
I send a get I get back a bunch of information that's then displayed on my web browser interface.
It's stateless.
Each request from client to server must contain all the information necessary to understand the request,
and it cannot take advantage of stored context on the server.
Session state is therefore entirely kept on the client.
That's very different to soap, which was an older way of implementing APIs in an enterprise.
In that example, state information is maintained on the server.
Here we don't maintain state on the server.
Everything needs to be maintained on the client.
Its also catchable cache constraints require that data within a response to a request be implicitly
or explicitly labeled as catchable or non catchable.
If a response is catchable, then a client cache is given the right to reuse that response data for
later equivalent requests.
You may have come across caching on your web browser many, many times.
Data is cached by web browsers.
Happens a lot.
If I want to force a page to refresh as an example, I have to press control or on a mac.
You sometimes have to re force a refresh of the page because stale information will be stored on your
local computer.
So something could be changed on the server, but you don't see the changes on your PC.
So on Windows and other browsers, you have to press control F5 to refresh the page and force a download
of all the elements such as the pictures and other information, rather than using a locally stored
cache of some of the information.
So we might not want everything stored in cache.
So rest API as an example and web servers will allow information to be cached on the local client rather
than pulling everything from the server.
Every time I go to a web page or make an API call.
Okay.
So that's enough about the principals have a read of this if you're interested.
They also talk about a resource key obstruction of information and rest is a resource.
Any information that can be named can be a resource which could be a document, an image, a service,
a collection of resources, etc., etc..
So I would suggest you have a quick read of some of this, but you're going to learn a lot more if I
just demonstrate this practically.
So that's what I'm going to do.
Now something else you'll come across is crud, which in computer programming means create, read,
update and delete and are for basic functions of persistent storage.
These are four actions performed by an application.
We could create something on a server.
We could read data from the server.
We could update something on the server, and we can delete information on the server.
Now I'm going to demonstrate the use of Postman in a moment, but notice here we've got get yeah, we've
got post, we've got delete, we've got patch, we've got other what are known as HTTP verbs.
So Post will allow me to create new data structures and variables.
That's the C in crud for create get allows me to read or retrieve a variable name structures and values
patch and put allow me to update or replace a values of some verbal and delete.
Fairly easy to understand allows me to delete variables and data structures.
Now postman and application are we going to use in a moment has those HTTP verbs, but it's not going
to mean much to you just by reading about this stuff.
It means a lot more if we just do it.
So I'm going to just show you practically how to do it.