We got the beginnings of our quest handler put together.
So now we're gonna start to implement the first couple steps in this flow.
We're going to try to find the order that the user is trying to pay for.
We'll make sure that the order belongs to this user and we'll also make sure that the order is not yet
cancelled.
So let's get to it back inside my editor.
I can remove that resource send statement and we will first pull out the token and the order I.D. from
the incoming request body.
We're going to have to refer to these two values right here a couple of times so it makes sense to just
pull them out of the request body right away.
I'm going to use the order model right here to try to find the appropriate order out of our database
there's a council order is a wait order but bind by I.D. and pass in the order I.D. then right away
if we are unable to find the appropriate order we should throw a not found error and say sorry we cannot
find the order you're trying to pay for.
There is no order or throw a new not found error
after that.
Well then check and see if the user who is trying to pay for this thing has the same I.D. as the orders
user I.D. property will say if order a dot user I.D. is not equal to rec not current user dot I.D. And
once again we're getting that little nasty thing from typescript where it's saying sorry we don't know
the current users defined.
We've been over this several times remember require authority has a very stringent check inside of it
to make sure that current user is defined.
So I'm gonna put the exclamation on there to say typescript Don't worry about it.
We already made sure that current user is defined so if those two ideas are not the same we should throw
probably a not authorized error they'll throw a new not authorized error and we should also import that
air from our common module as well.
I did not get that on the initial pass of all these imports so I'll throw in a not authorized air
yet.
And then finally we want to make sure that the order is not yet canceled.
We'll say if order not status is equal to order status not cancelled then let's throw a new bad request
air and we're making use of the order status e number right there which is coming from our common module.
Let's add in import for that at the very top as well.
So up at the top.
From our coming module we'll get our order status
whenever we throw a bad request error.
We also have to provide a reason to say hey here's why you made a bad request so I'll give this the
reason of something like in order to pay for an expired about cancelled order
so if we get past those three checks right there we'll say okay fine you can pay for this thing we'll
try to actually build your credit card to make sure that these three checks at least work we should
do a little quick intermediate test here.
So I'm going to restore that resource sense of success true.
Once again so now in theory we could test this out and try to make a variety of different requests using
postmen we get tried to pay for a order that does not actually exist.
We could tried to sign up as two different users create an order on one and then paper on another.
We could also tried to read an order.
Wait a minute.
But the thing to be expired and then tried to pay for it.
But all those scenarios sound like a lot of tedious work we would have to be using postman quite a bit
just to verify these different cases.
So I think that this is a great scenario where automated testing can make sure that we are doing the
correct thing in all three scenarios.
Let's take a pause right here.
We come back the next video we're gonna start to write out some automated tests to make sure that all
these different cases are handled appropriately.