[MUSIC]

Hello and welcome.

I'm Craig, and I'm a developer.

In this course, we're going to build a RESTful API using Spring.

It's going to support HATEOAS,

or Hypermedia as the Engine of Application State.

It's gonna integrate with Spring data and Spring security, and

provide self-documenting schema generation, almost seamlessly.

Now, word of warning.

You're probably going to get your mind blown by how much you can do with such

little code, and that's the beauty of Spring Boot at work.

But, before we take off,

please take a moment to check out the teacher's notes and make sure that you've

completed the prerequisites, just to make sure we're talking the same language.

Don't forget to check the notes on each video.

I usually drop helpful hints, tricks, and knowledge nuggets down there for

your consumption.

And, always remember the speed controls.

Feel free to speed me up or slow me way down.

I don't mind at all.

So let's talk about the project that we're gonna build together.

Now first off, imagine, if you will, that we work on an international team

that produces applications as requested by clients, you know, like an agency.

So we have a very well established client who has come to us and

asked us to build a course review system.

They want a single-page application website, an iPhone and Android app, and

of course, they want it yesterday, and our sales team told them it'd be no problem.

So, here we go.

So first off, a course review system is reviewing online courses, you know,

like this one you're watching here.

It'll be used to gather public opinion on those courses, so

people can make an educated decision on what they should watch.

Our team huddled together and

decided that we should tackle building out all the prototypes at the same time.

The approach that we came up with to do this joint team rapid development

is to produce a REST API, that all clients, you know,

the site and the different phone and tablet apps can consume.

So you've landed on the API creation team, arguably,

the most important team on getting this project launched, so good job.

So together,

we're going to build an API that allows anyone to submit courses to it, then we'll

also allow anyone to add reviews about the courses that have been submitted.

So, for instance, if someone wanted to add a review

to this workshop that you're watching right now, they'd do something like this.

So we have the client let us know the title and the URL.

Our project manager, her name's Hannah,

has assured us that that should be enough to get us started.

And now that this course that you are currently watching exists already,

we could have people submit reviews to it.

Now I know you haven't seen this yet, so these probably won't make too much sense,

but here are some reviews it's gotten.

So this has a rating of four out of a possible five and

a more detailed description, and someone else submitted this one.

That's not how you pronounce HATEOAS!

Well, hatters gonna hat, I guess.

So side note, if you feel like you're having deja vu, don't worry,

you might have seen this project used in another one of our courses here on

Treehouse, on a different web framework.

We're producing several workshops and courses in various other frameworks so you

can compare and contrast their approaches to building the same end product.

So the relationship is one course to many reviews.

One to many.

We'll also add the ability to walk from the review back to the course.

So that's many to one, right, from the perspective of the review.

It's many reviews to one course.

Now not only will our resource endpoints support all the HTTP verbs,

it will also be hypermedia driven.

It will be HATEOAS compliant.

Again, that's the Hypermedia as the Engine of Application State.

It's gonna be discoverable.

Someone can make a request, and our API will produce a list of all of its defined

relationships so that it can see what other actions are possible and

make a new request to other related resources.

For instance, when looking at a specific review,

it would have a relation link back to the course resource.

Now with the skills that you've picked up thus far, you could definitely build

a Spring MVC application that took care of all of this, right?

For example, we could build out our CourseController, and then we'd write some

handlers, and we could have some code that respond to an HTTP getRequest

to the courses endpoint, which would return a list of all available courses.

Yeah, we'd also need to convert those Java objects to JSON,

or JavaScript Object Notation, you know, the standard, so

that our clients can consume them.

And we'd also add one that creates a new course when the courses collection

is posted to.

We'll have to parse the JSON that was sent in and there's plenty of great tools for

that, many embedded in the Spring framework.

Now, as you've probably experienced from working with Spring,

it's the framework that keeps on giving.

Since this is a pretty repetitive task,

there are a lot of tools in Spring that help ease these monotonous tasks.

For instance,

there's an annotation that allows you to mark a controller as a REST controller.

It is, as you might expect.

So now, by default, you can return domain objects and they will be converted to

JSON, using a tool included in your Spring installation called Jackson.

We'll take a look at that here in a bit.

So that's great, but still, those controllers are probably going to end up

looking a lot like each other, right?

I mean, just about every application you can think of would work

pretty much like this, wouldn't it?

List of stuff, get the details of the stuff,

add more stuff, add some stuff that's related to that stuff, delete some stuff.

Sure, why not.

That's pretty repetitive, and believe me, code like this actually exists, and

you'll encounter it all over the place in all sorts of frameworks.

REST API Creation is usually a repetitive error prone task, and

when you introduce the concept of resource linking,

it quickly starts to become overwhelming in complexity.

There's so much to remember!

What standard should I adhere to?

There's got to be a better way, right?

I mean, if it's all doing the same process,

which is basically just exposing your data model to a client in the same format,

why should we developers have to write that over and over again?

I mean, we have better stuff to do.

We've got to change the world with our awesome app.

Now, what if I told you that Spring developers agreed with that

thought process and created a way to make sure that you

actually don't even have to write the controller piece at all.

Wouldn't that be awesome?

Well you've come to the right workshop, my friend.

Sit tight, here it comes.