Now in this lecture,
let me briefly come back to the question
when you should build an API or a web service,
and I'll use these terms interchangeably here
because when I say API here in this lecture,
I mean a URL-based API.
So in the end, the web service where we expose various URLs
to which other developers, other people can send requests
and where the main goal of these URLs
is to then return data, not HTML pages.
Of course, you probably already have an idea
of when you might wanna build such an API.
For example, if you're building an alternative to Stripe,
if you're building your own payment service
and you wanna expose that to the world,
but there also are other reasons and to understand those,
let's take a step back
and let's understand when a classic website
makes most sense.
So a website as we built it
multiple times throughout this course
where you have your views on the backend
and where it's all about returning HTML code
to the requester because the requester
typically is the browser where a user,
a visitor of your site,
entered some URL or clicked some link.
Now, such a website makes a lot of sense
if you want people to, well, view your website
and when your main product is the website itself.
So for example, if you're building a blog or an online shop,
then of course your website is the main product.
The online shop we built before in this course
is the product itself.
We would earn money by having that shop
where people can then buy something.
So in such a case,
such a traditional website makes a lot of sense
because we have this tight coupling of frontend and backend,
and we wanna render those dynamic pages,
which contain our products
or some user-specific data like cart and so on.
Now, when it comes to building a web API or web service,
then of course we have the case
that we wanna build something like Stripe.
Let's say Stripe doesn't exist yet
and we have the idea that such a service,
which other people can use,
where we help them handle payments would be a great idea.
We could then build such a service.
But there also is an alternative use case
which we haven't explored thus far
and that use case would be that we mostly wanna expose
some data in the end,
some data that can then be consumed from different clients
and I'll come back to this.
Now, the left case here,
building a web service like Stripe should be clear.
We have the goal of giving our developers,
customers access to this API.
Probably we will charge them for that,
but then they can use our service or API
to integrate it into their own products,
into their own sites or APIs.
Of course, we could also use such a service on our own.
If we are Stripe, we could use our ourselves,
we could use our own service in some other product
which might need payments
to offer some other service to end customers.
This, of course, would be possible.
We can become a customer of ourselves in this case,
probably without paying though.
Now, the right case is interesting though.
Of course, the borders are always kind of blurry,
but we could be building an API,
as we will do it throughout this course section,
where we don't necessarily offer a service
that is super useful to a lot of other developers.
Instead, we could build an API which offers, for example,
all these CRUD operations, create, read, update, and delete,
for managing to-do's or anything like this.
And then we could plan to use this ourselves,
but we might have different user-facing clients
that should be connected to this API.
And with user-facing clients, I mean things like browsers,
so a decoupled web frontend let's say,
so a static page in the end with no backend code
that might run on a different server,
but which uses Ajax to talk to our API,
to fetch data, send data and so on,
but also other clients,
like for example desktop or mobile apps.
Of course, we could be building a mobile app,
which lets users manage their daily to do's let's say,
and that mobile app would need to talk to some server
because we might not wanna store those to-do's
just on the user's device.
If the user switches the device,
all the to-do's would be gone.
We might wanna store them on our server
and our database instead.
Therefore, we need a server and we need a database,
but what we don't need in that case is HTML code and views.
Because if we're building a mobile app,
it turns out that those mobile apps
don't want HTML responses.
Instead, there you build the user interface
with totally different programming languages.
There is a reason why there are dedicated courses
teaching you mobile app development.
You build user interfaces with other tools there
with other languages, not necessarily with HTML and so on.
Therefore, such a mobile app might want the data,
but not the views, not the HTML code.
And that would be another use case.
We might not be building a service that's super useful
to a lot of other people in the world,
to a lot of other companies that should use it,
but instead we might be building an API
that's pretty much only useful to ourselves,
but we don't plan on just building a website.
Instead, we might wanna build such a mobile app
and therefore we don't need the frontend part.
We don't need the views.
We just want an API to which our mobile app can talk
so that it can fetch data from there
and then display it in its native user interface.
And this is also a common use case
that you need a backend, but not a frontend,
because your frontend might not be a website,
but instead a mobile app or desktop app.
Now still, it could also be a frontend.
It would also be very common
that you have different clients,
let's say browsers and mobile apps talking to the same API
because you might wanna have users on mobile devices
and users who visit your website through a browser.
This is also quite common.
If you think about Facebook or Google Maps
or basically any big company, you can visit their offerings,
you can visit Facebook through the browser
on your desktop device
or you can visit it through their mobile app.
And there, it is the case that the frontend on the browser
and the mobile app,
that these two are two totally different clients in the end,
but they probably talk to the same Facebook API
somewhere on some Facebook servers.
So that's also a use case.
And with this course section
and the overall knowledge you gained throughout this course,
you will be able to handle all these scenarios
and all these use cases.
So therefore, that was a lot of talking,
but now it's hopefully clear
why you might wanna build such APIs
and what possible use cases are.
Now, we're going to see this right case,
this data API case in action throughout this course section,
and therefore let's not waste any time
and instead dive right in.