Ticket #628 (closed Feature Request: worksforme)

Opened 7 years ago

Last modified 6 years ago

conflicting uris (e.g when creating entities via the REST-Service) should be distinguishable

Reported by: Malte Owned by: jri
Priority: Major Milestone:
Component: DeepaMehta Standard Distribution Version: 4.2
Keywords: Cc:
Complexity: 3 Area: Application Framework / API
Module:

Description

When communicating with DM this special case (an URI-conflict as a cause of error) should be distinguishable for a HTTP Client.

At the moment when topic could not be created (because there is already a topic with exactly this uri in the DM instance) just the generic 500 (Http Statuscode) is returned.

One suggestion would be to return "409 Conflict" in this special case as it is seems to be the Response-Status nearest to the actual semantics of the error, or how do you see it?

See also https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#4xx_Client_Error

Change History

comment:1 Changed 7 years ago by jri

I'm not sure about the benefit of such an error response. The client must catch the error anyway, investigate it, and then react accordingly. Instead, the client could check the conditional in advance and thus avoid the error at all. The resulting client code would be in no way more complex or difficult to write. On the contrary: it would be more clear.

comment:2 Changed 7 years ago by Malte

The benefit is imho clear:
DM responses would be distinguishable. For e.g. a JSONSyntaxParsingError is different from a URI-conflict error from a DatabaseError? from a <YouNameItError?> of which all? are currently wrapped in a "500 Internal Server Error", thus just allowing unspecific / generic error handling.

I like to code with custom exceptions (in Java) a lot because I find the resulting code (with dedicated exceptions for various edge-cases) more clear. Also, in the case dscribed here, the result performs one additional HTTP GET request just *if necessary* and not everytime in advance, resulting in a more efficient program-flow.

Additionally: Consider that someone might write a HTTP DM Client without access to server-side logs, then these distinctions (imo) should be as near to HTTP semantics as possible.

comment:3 Changed 7 years ago by jri

What I'm saying is: the check weather an URI exists already is part of your application logic. Your application logic must not be located in an exception handler. So, I would say, get your application logic right, and the error does not appear at all.

Later versions of DM might provide more differentiated error messages.

comment:4 Changed 6 years ago by jri

  • Status changed from new to closed
  • Resolution set to worksforme

A related issue is addressed in #442

Note: See TracTickets for help on using tickets.