[Geoserver-devel] [JIRA] (GEOS-10053) Return 410 instead of 404 for resource DELETE requests in REST API

GeoServer GeoServer Developer
1

Sander Schaminee created an issue

GeoServer / ImprovementGEOS-10053

Return 410 instead of 404 for resource DELETE requests in REST API

Issue Type:

ImprovementImprovement

Assignee:

Unassigned

Components:

REST

Created:

06/May/21 10:07 AM

Priority:

MediumMedium

Reporter:

Sander Schaminee

When I delete a style or layer using the GeoServer REST API, it returns a 404 whenever the style or layer no longer exists on the server.
In my opinion, it should only return a 404 if the URL is non-existing. For example, if the style resides within a workspace, it would be fine to return a 404 if the workspace name in the URL contained a typo.
404’s are also fine when doing GET/POST/PUT requests on layers or styles that do not exist.

However, when I do a DELETE and get a 404, there’s no way to tell if the resource simply does not exist (anymore) on the server, or that I made a typo in the URL.

I would like to propose to return a 410 instead in this case:

> 410 Gone
>
> This response is sent when the requested content has been permanently deleted from server, with no forwarding address. Clients are expected to remove their caches and links to the resource. The HTTP specification intends this status code to be used for “limited-time, promotional services”. APIs should not feel compelled to indicate resources that have been deleted with this status code.

Please let me know your thoughts on this matter.

Add Comment

Add Comment

Get Jira notifications on your phone! Download the Jira Cloud app for Android or iOS

This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100159-sha1:f2d09e5)

Atlassian logo
2

On Thursday, 6 May 2021 6:07:31 PM AEST Sander Schaminee (JIRA) wrote:

I would like to propose to return a *410 ( https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/410 )* instead in this case:
> 410 Gone
>
>
>
> This response is sent when the requested content has been permanently
> deleted from server, with no forwarding address. Clients are expected to
> remove their caches and links to the resource. The HTTP specification
> intends this status code to be used for "limited-time, promotional
> services". APIs should not feel compelled to indicate resources that have
> been deleted with this status code.

Please let me know your thoughts on this matter.

How can the server tell the difference between something that once existed but
is deleted, and something that never existed?

Even if it could, the semantics seems opposed to the last two sentence in the
part you quoted.

Brad

3

Hi Brad,
some systems just “soft delete” items in their database/configuration, as in, they mark them as deleted
with a field, without fully removing the information for some time.
This allows recovery in case of removal by mistake (for example, there are other reasons).

But GeoServer does nothing like that, once something it’s deleted from the config, it’s completely gone.

Cheers
Andrea

···

Regards, Andrea Aime

== GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.