Can you explain this transcript better "Instructor: In this video,

we'll cover Spring Data REST in Spring Boot.

Earlier, we saw the magic of Spring Data JPA, right?

So we had our entity type of employee

and our primary key of integer.

We plugged that in, and it'll give us those methods for free

for finding, saving, deleting, and so on.

And this really helped to eliminate the boilerplate codes.

And we saw this little diagram earlier, right?

The coding before Spring Data JPA,

and the coding after Spring Data JPA made it really easy.

No implementation class. Pretty awesome.

And I wonder like, "Hmm, can this same thing apply

to REST APIs?"

Hmm, I wonder.

So here's the problem.

We saw how to create a REST API for employee.

We would set up our employee REST controller,

inject a service, set up the get mappings,

post mappings, and so on.

We'd set up our service interface,

our service implementation,

and then we also had our application architecture.

We had our REST controller, our service, our repository.

And that worked fine and all.

But what if I needed to create a REST API

for another entity like customer, student, product or book?

Would I have to go back and repeat

all of the same code again?

And I don't wanna do that over and over again

for each entity.

I wish we could tell Spring,

"Hey, create a REST API for me,

use my existing JPArepository, my entity and primary key,

and give all of the basic REST API CRUD features for free."

So Spring Data REST is the solution.

It's a separate Spring project.

You can use it with regular Spring or Spring Boot.

It leverages your existing JPArepository,

and Spring will give you a REST CRUD implementation

for free.

And the nice thing here is that it helps

to minimize boilerplate REST code.

And in fact, there's no new coding required to get set up

with this Spring Data REST.

So Spring Data REST will expose these endpoints for free.

So you'll have methods for posting to create a new employee:

Get to retrieve, Put for update,

and Delete for, of course, deleting an existing employee.

And you get all of these REST endpoints for free

when you make use of Spring Data REST.

And again, just like magic.

So you may wonder: how does it work in the background?

Well, Spring Data REST will actually scan your project

for JPArepository sub interfaces.

It'll expose the REST API for each entity type

for your JPArepository.

So in this example here, I have this employee repository,

Extend JPArepository entity,

got this entity type of employee,

it will actually expose an employee's endpoint.

So a bit more on the endpoint here.

It will create the endpoints based on an entity type,

and it'll make use of the simple pluralized form,

meaning it'll take the first character of the entity type,

that's lowercase, and then it'll simply add an S

to the end of the entity.

So in this case, we have this employee repository.

The entity type is employee in brackets,

and then it'll create a /employees endpoint.

All right?

And so that's the basic approach

for how they'll expose these REST endpoints.

Now I'll talk more about the pluralized form later

in some later videos,

and also how you can kind of customize it.

But for now, we'll kind of take this out of the box.

All right, so let's look at the actual development process.

So for the first step is adding a Spring Data REST

to your Maven POM file, and that's it.

There's absolutely no coding required.

You simply make a Maven POM entry

and you get these endpoints for free.

So a bit more here on step one

is adding it to your POM file.

So you simply give a dependency here,

and you give a reference for Spring Boot Starter Data REST,

and that's it.

No coding required.

Spring Data REST will scan for JPArepositories

and expose endpoints.

And so you'll get these endpoints for free,

based on the various entity types in your JPArepositories.

So for Spring Data REST, you only need three items:

you need your entity type of employee; the JPArepository;

and then also the Maven POM dependency

for Spring Boot Starter Data REST.

So the first two items, we already have those.

The only new item here is number three,

the Maven POM dependency, and then that's it.

Now some changes to our application architecture here.

So before we had our employee REST controller,

we had our employee service

and our repository on the backend.

And now, after we're using Spring Data REST,

they'll give us a /employees endpoint for free.

So there's no additional coding required

to get this given REST endpoint.

So in our original architecture up top,

we can delete the code from our employee REST controller

and also delete the employee service.

We no longer need that code,

because Spring Data REST will provide that functionality

for us for free.

And ooh, I like free stuff.

Now with minimizing the boilerplate code.

So before Spring Data REST, we had our REST controller,

we had our employee service,

we had our service implementation,

so about three files and 100 plus lines of code.

And then after Spring Data REST,

you're gonna love this, right?

No coding required. Just give a Maven POM entry.

Spring Data REST will scan for those repositories,

and automatically expose those endpoints for free.

You can easily see that we no longer need

their original code on the left hand side,

because Spring Data REST will give us

all of that functionality for free.

The Spring Data REST endpoints are HATEOAS compliant.

So what is HATEOAS?

It's the Hypermedia As The Engine Of Application State.

Blah, big acronym.

Basically, hypermedia-driven sites that provide information

to access our REST interfaces.

And so really, you can just think of this as metadata

for the REST data

that's coming back from these given REST APIs.

You can read more about HATEOAS at this link here,

at Spring.io,

but I'll actually go through some quick examples

to show you the basics of how this HATEOAS works.

Spring Data REST responses make use of HATEOAS.

So for example, a REST response from Get/Employee/3

to get a single employee.

Then it'll return this JSON data as a response.

So up top we'll actually have our content or our real data,

like our employee data,

first name, last name, email for given employee.

And then at the bottom we actually have response metadata.

So this metadata here basically has links

to the actual entry or the data.

So this is for employee ID of number three.

Just a way of describing the data or linking to the data.

Now for a collection, the metadata includes the page size,

the total number of elements, the pages, and so on.

So if I wanted to get a list of employees

by doing GET/employees,

then the JSON response will be

this piece of information here.

And up top we have embedded a JSON array of employees

for all the different employees there.

And then down at the bottom, we have metadata about the page

or information about the page.

So the size of the page, this total number of elements,

pages, number, and so on.

And I'll talk more about configuring

the page sizes a little bit later.

So for details on HATEOAS, see the link here at Spring.io.

HATEOAS also makes use of the Hypertext Application Language

data format or HAL,

and that's the actual format of the JSON data

that's being returned in the response.

So, if you'd like to get more information on HAL,

you can see the link here at the Wikipedia website.

Spring Data REST also has some advanced features.

So there's support for a pagination, sorting and searching.

You can also extend and add custom queries with JPQL.

You can also customize the REST API by making use

of the query domain specific language or the query DSL.

For more information, you can see the link here

at Spring.io, Spring Data REST."