Hi there, this is Scott Duffy from SoftwareArchitect.ca.
In this video, I'm going to address
something a little complicated.
It's on the term REST and RESTful services.
What is REST and what do you use it for?
So, REST is an acronym, REST.
It stands for representational state transfer.
As the name implies, it has to do with client
and server relationship and how state is stored.
Now, early days of web development,
it became needed that the server side
of a web application needed to remember
certain details about the user that's using it.
I'll give you an example.
If you're going to write an application
in classic ASP, nobody does that anymore,
and somebody logs in and you want to store their username
and a couple of other pieces of information
you need about them, you could store their username
in a session variable on the server.
What would happen is that the server
would then reserve a little bit of memory for that user,
and that's what it's called, a session,
and so the more users you get,
the more little bits of memory would get taken up
and if you had an application that needed
to serve thousands of people at the same time,
the memory would quickly be full
and your server application would come to a halt
and you'd have very real performance problems
and scaling problems when you had an application
that used server side memory to store.
Now, the advancement in that became
storing this state in a database.
ASP.net has such a thing called
a session server, a session state,
and you could then just store a small token,
and that would be passed between the client and server
and then server would be able to go look up in a database
the information it needed about that user using that token.
The further advancement of this is this concept of REST.
The concept of REST is that the client passes to the server
everything that the server needs to perform the action
and then the server does it, returns to the client
with the action complete, and that's it.
It's a process that is complete.
You make a request, the request gets fulfilled, done.
I do not need to remember you.
I do not have anything sitting on the server that tells me
that I have to remember the following five facts.
If you need five facts, those get passed.
Now, there are other concepts in REST.
So, for instance, RESTful service often make use
of the HTTP specification to a fuller extent.
This is no surprise because the person
who came up with the idea for RESTful service
is also the same person that defined the HTTP specification.
So, instead of just getting information
or posting information, a RESTful service
often does put operations, delete operations.
There are other post types beyond
get and post that HTTP recommends
and so RESTful services implement those.
The third thing that you'll find
in common with a lot of RESTful services
are that there is a URL structure and oftentimes
you'll end up with action slash ID slash parameter slash,
like the URL of the request contains
information that the server needs,
and so instead of a URL representing a directory structure
and a specific file in a specific folder,
in a RESTful service, oftentimes you get to a point
where the rest of the URL represents data
and is oftentimes an ID, et cetera.
And finally, a RESTful service uses
typical XML web services notation,
and so that could be returning XML output or JSON output.
You're not going to see RESTful services returning HTML
that just gets dumped to the client.
There's some interpretation required.
So those are the four basic properties of a RESTful service
and so hopefully that made sense.
A RESTful service, the fundamental thing
is it does not maintain the state on the server
that the client passes everything that it needs
as part of the URL structure or in the header.
If there's an authentication token or other
that needs to be passed, it is part of a HTTP header.
It uses the full range of HTTP properties
and then it uses XML or JSON to return back to the user,
back to the client to be further processed.
So, that's my attempt at explaining the RESTful service.
If that wasn't clear or you have any questions about REST
or XML web services, leave 'em in the comments.
This is Scott from SoftwareArchitect.ca
and talk to you soon, thank you.
Thank you so much for watching.
Click the thumbs up button if you liked this video.
There is the subscribe button down below
if you want to see more videos like this as I create them.
On the right is another video about
software architecture that you might enjoy.
On the left, I actually have a course on architecture.
I want you to check it out.
Up above is my web site, if you want to go there.
We have some blog articles, things like that.
And finally, if you have any questions about
software enterprise architecture,
just leave 'em in the comments on YouTube channel
and I'd be happy to talk to you there.
Thanks again and I hope to see you again.