McVutt
McVutt

Reputation: 11

Slim Framework v3 - REST API - Delete

I am currently in the process of learning how to buid my own REST API using the Slim Framework v3 for PHP. I found several tutorials and was able to build multiple routes to send GET and POST requests to my MySQL database.

Next up for me is a delete request. I found a tutorial which showed the following piece of code:

$app->delete('/todo/[{id}]', function ($request, $response, $args) {
     $sth = $this->db->prepare("DELETE FROM tasks WHERE id=:id");
    $sth->bindParam("id", $args['id']);
    $sth->execute();
    $todos = $sth->fetchAll();
    return $this->response->withJson($todos);
});

Beforehand I made my delete route (is that the correct usage of these terms?) almost the same, except that I did not return anything. This piece of code got me wondering: Is it "common" that a delete request returns something? From my understanding this request is supposed to return all other entries from the table "tasks" - Is that good practice? Is it "good" practice in general if the delete request returns something - If yes: What? I am trying to adapt to the most common practices.

On a side note: I tried to use quoted request like that and was able to delete something as usual. However, it does not return anything at all.

The error is the following:

[...]
        <h1>Slim Application Error</h1>
        <p>The application could not run because of the following error:</p>
        <h2>Details</h2>
        <div>
            <strong>Type:</strong> PDOException
        </div>
        <div>
            <strong>Code:</strong> HY000
        </div>
        <div>
            <strong>Message:</strong> SQLSTATE[HY000]: General error
        </div>
        <div>
            <strong>File:</strong> /www/htdocs/src/routes.php
        </div>
        <div>
            <strong>Line:</strong> 68
        </div>
[...]

Line 68 is in my case "$todos = $sth->fetchAll();".

To add another question regarding "good practice": I would like to check whether the ID which is given through the delete request exists or not - Is that something which I would include in the routing (the check if it exists)? Or is there another practice for checks like that?

Thanks a lot.

Upvotes: 1

Views: 2032

Answers (1)

Georgy Ivanov
Georgy Ivanov

Reputation: 1579

Is it "common" that a delete request returns something?

Is it "good" practice in general if the delete request returns something - If yes: What? I am trying to adapt to the most common practices.

I'd say it's mandatory to return something. Delete is an operation like any other, so when client of your API calls delete procedure on particular entity, they want to know if the entity was actually deleted. Thus you should return something.

How should you return it?

Note, this is just my opinion.

Normally REST APIs are "bound" to protocol (HTTP), and HTTP provides an excellent option to display result of a request: status codes. You have 200 OK, 404 Not Found, 500 Internal Server Error, etc. Here is the reference for HTTP codes.

Provided you use them appropriately even a developer who is not well aquantied to your API will understand them and act accordingly.

For a "delete entity with this ID" operation, I'd use the following codes:

  • 404 Not Found: if there is no entity with this ID in the database;
  • 400 Bad Request: if an ID in the URL is invalid (i.e. is not a positive integer); or you could use 404 for this scenario, actually.
  • 500 Internal Server Error: if something on your side fails. Like database operation fail;
  • 200 OK: if delete operation was successfull.

Any web-developer who has at some experience knows these codes very well, so they will understand results easily.

From my understanding this request is supposed to return all other entries from the table "tasks" - Is that good practice?

No, not really. This request invokes "delete this task" procedure and should return only result of this particular operation. Take PDO for example: when you call "DELETE FROM tasks WHERE id=:id" it returns boolean value that indicates if operation was successfull; it doesn't return other records from the table. So, apply same simple logic here.

Upvotes: 1

Related Questions