WEBVTT

00:00.640 --> 00:04.240
So we can continue by creating the REST Express

00:04.320 --> 00:07.360
routers, which we need for our application to be working via rest.

00:07.920 --> 00:11.600
We will create a separate folder called Routes

00:12.720 --> 00:16.320
and then we will create two routes, one for the companies,

00:18.480 --> 00:20.960
another for shareholders.

00:25.040 --> 00:28.680
Cool. So. So we also can use the GitHub copilot to help us generate the

00:29.180 --> 00:32.600
REST routes because it's a relatively common use case. And let's see what it

00:33.100 --> 00:33.440
will propose to us.

00:38.400 --> 00:41.679
So you can see it create like a default schema for all of

00:42.179 --> 00:44.440
the requests because it doesn't actually know what to do within it, at least for

00:44.940 --> 00:47.920
now. So we will accept it. We do not need all of them.

00:48.320 --> 00:52.820
So we would need to start by changing the base URL and

00:53.320 --> 00:54.780
the base URL for our application.

00:57.100 --> 01:00.380
We just use the default RESTful model in this specific case.

01:00.620 --> 01:03.260
And then let's see what we can do here.

01:04.220 --> 01:07.460
We already have our mongoose models and so

01:07.960 --> 01:11.380
it will import the request response from the express and then it will

01:11.880 --> 01:15.340
add the company and the company interface. And then

01:15.840 --> 01:19.020
actually we'll do the default magic to hook it up and return the response,

01:19.100 --> 01:22.190
but the user. So we can use this one because that's the default we actually

01:22.690 --> 01:26.110
need. We do not need to do anything extra specifically here because we don't want

01:26.610 --> 01:29.590
to change anything. But you can align it to the best of your knowledge and

01:30.090 --> 01:34.070
the best practices. Let's see why it doesn't like it. Actually, let's also

01:34.570 --> 01:37.910
use the fix from the copilot

01:44.230 --> 01:47.530
and this is the fix. Amazing. So you can

01:48.030 --> 01:51.010
also use GitHub GitHub copilot to fix it, but we will go deeper in that

01:51.510 --> 01:55.530
in the later section and we can do the same for every

01:56.030 --> 01:57.410
route. Let's see what it will suggest.

01:59.250 --> 02:02.850
Company wait, find by ID return if it's not found and then we have a

02:03.350 --> 02:06.530
company and then we failed. Okay, that sounds nice, at least as a starter,

02:07.030 --> 02:10.370
because we don't need to over complicate it. And let's do the same here.

02:11.480 --> 02:15.000
See, so we have name

02:15.500 --> 02:19.240
description from the body. It suggests us that we're going to send name and description

02:19.740 --> 02:23.040
even though we don't have this property. But it also will create

02:23.540 --> 02:27.080
a company. We'll wait to save it and then respond with it, or respond

02:27.580 --> 02:30.840
with 500, which is fine, we will just need to correct. So in

02:31.340 --> 02:34.520
this case it was a mistake because it's not that smart in order to understand

02:35.020 --> 02:39.270
what is the part of the company itself, name and

02:39.430 --> 02:42.750
shares. So this would be required, even though in most of the cases,

02:43.250 --> 02:45.910
at least for our application capitalization and shares would be zero,

02:46.870 --> 02:48.710
but we can actually define it.

02:53.990 --> 02:57.590
So we can define the default value just in case the

02:58.090 --> 03:01.750
the user don't want to send it. And what we can do on top

03:02.250 --> 03:05.350
of that is to finalize with boot and delete.