All language subtitles for 017 Making the API Better_ Limiting Fields_Downloadly.ir_en

As the next feature in our API,

we have field limiting,

so, basically, in order to allow clients

to choose which fields they want

to get back in the response.

So, for a client, it's always ideal

to receive as little data as possible,

in order to reduce the bandwidth

that is consumed with each request.

And that's, of course, especially true

when we have really data-heavy data sets, right?

And so it's a very nice feature

to allow the API user to only request some of the fields.

So, as the third feature, we will have field limiting.

And, just like before, let me start by showing you

how it's gonna work here in Postman.

So, we're gonna specify a field called fields,

and then the name of the fields

that we actually want to receive.

So let's say we only want the name,

the duration,

the difficulty, and the price, all right.

And so, the implementation will actually be very similar

to what we did before with sorting.

So, if req.query.fields,

then let's actually, again, create a variable

for these fields here because just like before,

Mongodbs, actually requests a string

with the field name separated by spaces, all right?

Now let me actually start by writing out

that part, okay, so, the query itself.

So query is equal to query.select, okay?

And here, for example, it expects a string like,

name then space, duration and a price for example, okay.

And so this way, it will only select

these three field names and send back

the result only containing that, okay?

And actually, this operation of selecting

only certain field names is called projecting okay?

So, let's now go ahead and create basically,

the string, just like we did up there okay.

So we start with req.query.fields,

then we split it by a comma,

and join it with an empty string.

With a space actually, sorry.

So with the space and so that's, then,

gonna produce this exact string with this exact format.

Then here, all we have to do is to use these fields.

Then, just like before, I also want to add a default

so in case the user does not specify the fields field,

okay, so, in that case, we will just

actually remove something, okay?

And let me show that to you first, so down here,

we always have this underscore underscore V,

which is set to zero, and Mongodbs just creates these fields

because it uses them internally.

And we could disable them, but that's not a good practice.

Again, because Mongodbs actually uses them, alright,

but what we can do is to basically

never send them to the client, so we can exclude them.

And the way we do that is to, instead of doing

underscore underscore V like before,

so like we did up here, basically,

we just prefix it with a minus, okay?

And minus is then not including, but excluding.

So what we had before here again,

with the name and duration and price,

that was to include these fields in the response.

But this way, with the minus,

we have everything except the V field here okay?

So we're excluding only this field, alright?

So let's go ahead and test that.

Send it, and let's wait for it and yeah, indeed so,

the ID is by default, always including okay?

So we cannot remove that, but besides that,

we have just the name, duration, difficulty, and price,

okay, and we could, of course, also use that minus

so that exclusion here as well.

So we could have everything, minus the name

and minus the duration, for example.

So let's test that as well.

And so, if you now check it, you will not see the name,

and not see the duration anywhere here.

Right, and now just as a final test,

let's see if our default works as well.

Sending the response and so, now we no longer have

that V variable here set to zero in all the documents.

All right, great, now there's one last thing

that I want to show you which is that

we can also exclude fields right from the schema.

Alright, and that can be very useful,

for example, when we have sensitive data

that should only be used internally.

For example, stuff like passwords

should never be exposed to the client

and so therefore, we can exclude

some fields right in the schema.

So for example, we might not want the user

to see when exactly each tour was created.

For example, tour might already be

kind of old or something and so,

let's say we want to always hide this createdAt field,

alright, so we can go into our schema,

which is in the tour model of course,

and then at createdAt, we simply set

the select property here to false.

And now when we try to get our results,

you see that it's actually no longer there okay?

And so like this, we can basically,

permanently hide this from the output.

Perfect, so one more feature that is actually working now

and so let's now move on right to the next one.