Implementing a restore function for soft deletable models

[jannis-a]

Hi again, I'm currently implementing the restore functionality for my soft-deletable models. I decided doing this via a PATCH request, an empty body and a custom header (X-Restore). I think the place to realize this is the update method on the adapter. The only problem is, when I tried to make this special request to a deleted model i receive a 404. How do I use another query when this special request is made? Or am I doing it totally wrong? :sweat_smile:

Best regards Jannis

[lindyhopchris]

Hi,

We're planning on adding full soft-delete support, as there's been a lot of discussion about this on https://github.com/cloudcreativity/laravel-json-api/issues/106

The plan will be that this request will soft-delete:

PATCH /posts/123
Content-Type: application/vnd.api+json
Accept: application/vnd.api+json

{
  "data": {
    "type": "posts",
    "id": "123",
    "attributes": {
      "deleted-at": "2018-10-30T17:00:00Z"
    }
  }
}

This will restore:

PATCH /posts/123
Content-Type: application/vnd.api+json
Accept: application/vnd.api+json

{
  "data": {
    "type": "posts",
    "id": "123",
    "attributes": {
      "deleted-at": null
    }
  }
}

And this will hard-delete:

DELETE /posts/123
Accept: application/vnd.api+json

[lindyhopchris]

The deleted-at field will be customisable and we'll make it that you can use booleans instead of dates if preferred.

[jannis-a]

Great news!

But the question of using another query is still left open. Imagine having an API for an admin panel. This API should return soft-deleted models. How can this be done?

[lindyhopchris]

So at the moment you'd need to overload a number of methods in the Eloquent adapter, the primary one being newQuery() to make sure that always returned a query builder that has had withTrashed() called on it, e.g.:

return parent::newQuery()->withTrashed();

[jannis-a]

Thanks for that hint.

If there will be library built-in support for soft deletes, do you plan supporting returning soft-deleted entries?

[lindyhopchris]

Yep!

[jannis-a]

Nice, keep up the really great work!

[JeanLucEsser]

THIS is the way to soft delete. Thank you @lindyhopchris for implementing this, but I still wonder why you had to do it as I think it's App specific. Anyway, you decided to do it, and the right way, so there's that. Of course the deleted-at field should be customizable, but in an objet way, for instance we could have a status object with updated-at, created-at and deleted-at properties inside:

"status": {
  "created-at": "2018-10-30T17:00:00Z",
  "updated-at": "2018-10-30T17:00:00Z",
  "deleted-at": null
}

Another thing to keep in mind is allowing for manual setting of the value of the deleted-at field, as there are applications that rely on that precise value which could be any date but now().

Then getting a list of resources including trashed items should be done via filters (or via a separate api) but not with specific rights. The same endpoint should return the same kind of resources.

• api/v1/posts should return non trashed items for regular users as well as for admins.

• api/v1/posts?filter[status]=with-trashed should be able to return trashed items for regular users as well as for admins, only that regular users won't get them because of their specific rights.

• api/v1/posts/:id should always return a post, no matter its trashed status.

But again, all of this is very App specific, to each its own I guess, there are some other ways of doing this, including creating a trashed endpoint on the resource.