Create Three Symfony Back Ends - Part #10 - GET one resource

We've done most of the hard work at this point

We have a working test suite and we can post in new data, validate it and save it to the database

In this video, we're going to implement the get functionality for a single album

So let's quickly recap our B hat test scenario for a single album get request

So we've covered how the background step sets up our database with three albums before each scenario

and that the before scenario hook should truncate our album table to ensure that the auto-incrementing ID always resets to one

This way we can test that when we send in a get request for an album with ID1

we're always going to get back that first album. We already have our album controller

so we only need to add in a new method in this file to handle get requests

So let's start by doing just that. We're not in a new public function, which I'm going to call get

and I'm going to annotate this function with the routing annotation, setting the route to slash album slash ID, where ID is the placeholder

And I'm going to name the root get underscore album. You can of course name your roots anything that you like

but sticking with the convention of verb underscore resource seems most logical to me

Whereas for our post method, we restricted down to just the post verb

Here I'm restricting down to just get requests. Now, if you haven't worked with Symphony before

and these routing annotations are new to you, the only thing that's different between this and the post request

is that here we're using the routing placeholder of ID. And if we set this as an argument on our get method

then Symphony's going to take care of passing the. argument in for us. Now what I would always recommend is after making a routing change

just check the debug router output to ensure that your new route is in there and it also

looks the way you expect it to. Now there's one additional step that I'm going to take

As we only want integer values to be requestable, let's use a regular expression in the

requirements pattern to restrict the placeholder of ID to match just positive numbers

Now with that change in mind we could add extra tests into our symphony for Edgecase feature to check for some of these unwanted routes The tests are very straightforward We just want to check that we can send in a request for an alpha numeric ID

and also that the integer has to be positive. And at this stage, the test should be passing without further intervention on our part

Now, this is good, and Symphony's helped us quite a lot here, but we haven't actually tackled the happy path as of yet

We're just aware of some unhappy paths that we don't want. So let's get back to testing the happy path

So as the router is now helping us make sure only numeric values are making the way through to our controller code

we can now use this ID variable to look up an existing album. To accomplish this task, we'll use the album repository

And this was generated for us earlier when we used to the symphony maker bundle to make our entity

We get access to the album repository, just like we get access to any other service in a symphony four application via dependency injection

As we'll likely want access to the album repository from not just our get controller method

but from put and patch and delete to, it makes sense to inject the album repository in by the constructor

rather than just into this specific get method. So with the album repository injected and set as a private property on our controller class

we can now use it from our get method to look up the album matching the given ID

Now the album repository offers us direct access to various standard doctrine repository methods

such as find, find by, find one by, find all, and so on

We're going to use find, which takes an ID, and all being well, returns us an album with that ID

Now, you don't need to do this next step, but the local album variable is redundant here

We can inline the find call directly on the response, but this may be a little bit confusing

So if unsure, just know that these two are doing exactly the same thing, and either way should honestly be fine

Now, you could make this process even more streamlined by using a param converter to automatically convert the given ID to the matching album entity

Feel free to add this to your project There a link in the show notes So we should be able to go ahead and start testing this implementation because on the surface of it things look good at this point I just going to take the T tags off those two

tests that I don't want to run and just add that T tag to our album get request, just so we're

only running one test. And now let's send that in. And somewhat unexpectedly, this test fails

and it fails quite spectacularly, with a bit of a long-winded and rather scary-looking error message

Now, my best advice is whenever you see something like this in B-Hat, just run the test manually from Postman or whichever client that you prefer and see what you actually get

And here you can see, we're just getting back an empty object. We're actually getting that 200 status code

So things look like the semi-okay. But the issue here is just because we're returning a JSON response

Symphony won't just go ahead and JSON encode or serialize our album entity for us

Now, again, this is something that both API Platform and FOSREST bundle

will make easier for us. This just works in that case. Here, though, we need to do a little more work

Now, achieving this in PHP isn't so hard. Symphony can trigger a JSON encode on our album entity

but we need to tell it how to convert an album to Jason. And to do this, we need to implement the JSON serializable interface on our entity

And by implementing Jason serializable, we're essentially contractually obligated to implement the extra public method of Jason

serializable, which needs to return an array. and all we need to do is fill out exactly what we want to return

which in our case will be everything, but it needn't be. And notice how I'm changing the property names from camel case to snake case

Now if we send in our request again, then things look a lot better. But they're not quite perfect though yet

We need to format the date output a little bit further. So from the release date, which is a date time

I'm going to call format and pass in the format of date time atom

which is just a constant, which resolves to the string that you're seeing on screen

right now. There are others available, so please see the show notes for a direct link

And this should be enough to satisfy our B test suite at this point for a single album get request So if we switch back to our B test suite now and send in the only test with the tag of T well I was expecting that to pass honestly

But let's take a quick look at what's happened here. So we've got a value mismatch for key title

in the haystack of object. So that seems unusual. This should be working

The database should be back to its known good state. And I think that actually is the problem

We did in a previous video take out the before scenario. hook by putting a space after the at, and so our album table isn't getting truncated after each

scenario has been run. So there we go, that looks a lot better. Now there's one extra thing to

consider, and that's what happens if a resource doesn't exist. But what would happen if we

ask for, say, the album with the idea of 100, which we know definitely doesn't exist

Well, let's send that in, and somewhat unexpectedly, we're getting back a 200 OK, and perhaps we

should be getting a 404. So I'm going to add in another edge case test for this

And we know that this test is going to be failing at the moment. Now, there are likely multiple ways that we could solve this

But I know that we're going to need to look up an album by ID in more than just our get method

We're going to need to do this in both put and patch and also delete

So what I'm going to do is I'm going to extract this process out to a private function called find album by ID

Inside this function, we're going to do the same process. We're going to use the album repository to try and find the given ID

and then we're going to check if the response from that call is null

then we're going to throw a not found HTTP exception, which is going to throw a 404 in effect

However, if we do find the album, then we will just return it. This means anywhere in our controller class

where we would like to look for an album, we'll use that internal private function

rather than a direct call to the repository. So with this change made, we can send in a manual test

and we can see that we're getting back our 404 not found, and that should mean if we're sending our B

test we now have a pass which we do so that's good okay so we seem all done here onwards to

getting a collection of albums