Now, that is where REST APIs come into play.
This is a specific pattern of building URL-based APIs.
So when you say that you build a REST API,
you build such a URL-based API by following certain rules,
which are not officially standardized,
but common ground, you could say.
REST stands for representational state transfer,
but it's not too important actually,
what's more important is how it actually works
and how you build REST APIs.
And whilst there are more details to it,
which you can dive into,
there is one really important core rule,
which you will see in all REST APIs
or APIs that call themselves REST APIs out there.
Because REST indeed is the most popular
and common form of building APIs,
and you will therefore for see it a lot.
Now, that one rule which I mentioned is in the end
that you have these endpoints,
these URL, HTTP method combinations,
and every such endpoint maps to a certain action.
For example, we could have an endpoint, a route,
in our backend code, where we expect a GET request
to a path named /cars, so our domain /cars.
And for incoming GET requests to this path,
we might then return a list of available cars.
For example, if we're building a car rental service,
then this could be one of our endpoints.
And of course, we could have more endpoints,
and we could have a bunch of HTTP method, URL
or path combinations that then trigger different actions.
Besides the GET /cars, example I already showed you,
we could, for example, except POST requests
to our domain.com/rental,
which could create a new rental request,
if we are building a car rental service,
and then of course, return a response that contains
whether the request was confirmed or declined, for example.
We could accept PUT requests to a rental process
that has a certain ID assigned to it,
which would allow us to update that rental data piece
or a PATCH request to update some user data
or a DELETE request to cancel the rental of a car.
And these are just some dummy examples,
but the idea hopefully is clear.
We build such a Web service as a REST API
by defining a couple of routes
where the HTTP method path combination is very important,
and then our users, our customers, of our service,
can send requests to these specific endpoints
to trigger certain actions or get back certain responses.
That's the idea behind REST APIs in the end,
and that, as mentioned, is the most common form of APIs,
the most common approach of building Web APIs.
Nonetheless, there is something which I have highlighted
before in the course, which I wanna highlight again.
Even though we have all these nice combinations here,
it's still the backend code dead really matters in the end.
It's the backend code that decides what actually happens.
Of course, we have these endpoints
and we set them up following certain conventions.
For example, we would create a endpoint
in our route configuration
that wants the DELETE request method for deleting some data,
but these are just conventions.
What actually happens on our server
is only decided by our backend code.
We could theoretically set up a route
that wants a GET request to a certain path
where we then delete some data on the backend,
this just wouldn't make sense.
So as the developer creating such a Web service,
we typically come up with endpoints,
so with request method, URL or path combinations
that also give the sender of the request
a clear idea of what is likely to happen.
Of course, in addition,
we should also provide clear documentation,
written documentation, if we plan on selling a service
to others, but the endpoints should already give
a first clue of what's probably going to happen.
Now, in this course section,
we're going to learn how to build such a REST API,
because as mentioned,
that is the most common form of an API.
I still also wanna mention that there are alternatives
because the REST is just a pattern for building Web APIs,
and of course, there are also different patterns.
Alternatives would, for example, be the SOAP API,
though, to be very honest, that's not too important anymore,
you don't really need to learn that
unless you really work on a project
where you are forced to use that,
but a very popular alternative to REST APIs
are GraphQL APIs.
This is a pattern developed by Facebook,
and here, for example, you don't have different endpoints
with different request method path combinations.
Instead, there you have just one endpoint,
which is a POST request to some path of your choice,
and then it's the data that's part of the request
that describes what should happen on the server.
It's a totally different topic.
I do dive into GraphQL APIs in my NodeJS course,
if you're interested in that, but still,
as I mentioned before, REST APIs or APIs that are similar
to the concepts implied by the REST API approach
are the most common form of APIs, and therefore,
that's what we'll dive into in this course section.
And with that enough of the theory,
we're now going to get our hands dirty
and build our first API together now,
and for then, we're going to start with a simple example
and we're going to build our own Web service
with a web-based API that allows users of that service,
no matter if that's ourselves on our decoupled frontend
or other developers with their own sites,
to send requests to that API to get a daily quote.
So when our request reaches this route,
we wanna retrieve and return a random daily quote.
Now, we're not going to add endpoints
for storing daily quotes because that's not a feature
this service will provide to our customers.
Instead, the that is something which we,
as the service administrator,
could do through some other API,
which is not exposed to the public,
or as we will do it here, by directly manipulating
the database with database queries.
This is what we're going to build,
and we're going to build it from the ground up
with Node, Express and MongoDB, though, of course,
I wanna emphasize that you could use
any programming language, any framework for that language,
and of course, also any database.
You could also build Web APIs with MySQL.
That would work just fine as well.