API - DELETE

In this final video in the API setup section we will implement the DELETE verb by creating a deleteAction. FOSRESTBundle will be able to infer from our action name that this will expect users to send in DELETE requests when interacting with this endpoint.

The endpoint itself will use a URL in the format:

DELETE /posts/{id}

From previous videos, we know that we need to check that the request BlogPost / $id actually exists before trying to delete it, or we will likely end up throwing a big old error instead.

Much like the previous video write ups, let's first recap the full action, and then go line-by-line:

    public function deleteAction(int $id)
    {
        /**
         * @var $blogPost BlogPost
         */
        $blogPost = $this->getBlogPostRepository()->find($id);

        if ($blogPost === null) {
            return new View(null, Response::HTTP_NOT_FOUND);
        }

        $em = $this->getDoctrine()->getManager();
        $em->remove($blogPost);
        $em->flush();

        return new View(null, Response::HTTP_NO_CONTENT);
    }

Ok, that's the whole of the code required to implement our basic DELETE functionality.

Let's review the steps individually:

    public function deleteAction(int $id)
    {
        /**
         * @var $blogPost BlogPost
         */
        $blogPost = $this->getBlogPostRepository()->find($id);

First off we use PHP7 type hints to check that the passed in $id is definitely an int. No point allowing uses to attempt deletes on strings!

Assuming the user isn't a total chimp, the next thing we do is a Doctrine find query against the given $id number.

This may return a null. This is going to lead to bad times if we aren't a little defensive, so:

        if ($blogPost === null) {
            return new View(null, Response::HTTP_NOT_FOUND);
        }

We do our second chimp-check.

If the user is trying to delete a non-existant BlogPost resource then we will throw a 404.

Some API's will throw 404 errors if you attempt to delete resources that exist but that you don't have access too. Don't be one of those developers. Try your best to use the right status codes. If in doubt, enhance your calm.

Assuming we haven't thrown a 404 by this stage, we must be working with a real entity.

The next three steps do the removal job:

        $em = $this->getDoctrine()->getManager();
        $em->remove($blogPost);
        $em->flush();

If any of this is new to you, I'd strongly advise you watch this video where you will learn about Read, Update, and Delete in Doctrine.

The entity is now gone. Rejoice. Unless you accidentally removed the wrong entity... oops?

Anyway, let's assume you didn't... and even if you did, this next step happens anyway:

        return new View(null, Response::HTTP_NO_CONTENT);

We have no content, no link, not much actually. So instead we simply say things went well, here's a 204 status code.

And that's it. Fairly painless all round.

The harder part comes in ensuring that either the user doesn't or shouldn't be deleting this record. The actual delete is easy enough. Life would be much simpler without users :)

At this stage our API is good enough to start the Angular and React implementations. So that is exactly what we will do in the very next video.