Ticket #628 (closed Feature Request: worksforme)
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:2 Changed 11 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 11 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.
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.