Develop Reference

REST API - how to deal with post and functional errors

I have a REST service which is a POST to create a user, if the user does not exist, the user is created, and the service returns a 200 with the user in a json format.
Case 1: What if the user exists already, do I return a functionnal exception, so a json containing an error (all of this managed by the error handling of spring boot), and what about the http status code
Some people say to send a 303 or a 409 ... many different answers, and what about the response body in that case?
Case 2: What if in the backend we have let say a rule on the name (like containing a space) which returns an error (space not allowed in a name), same questions, do i have to return a functionnal exception and what about the http status code in this case
Somehow I want the API consumer to know what kind of json structure to handle and i guess the http status code helps for that ?

It all depends on how one interprets the various http status codes and how user friendly do you want your HTTP payload responses to be. Below are few suggestions:
NEW USER CREATED : If its a new user and gets created successfully in the backend then you return http status code 201. This is a technical status code. You can also return a functional status in the response body mentioning "User created"
https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/201
USER ALREADY EXISTS : If the user already exists, you should respond with http status code 200 with a response payload body mentioning a functional status "User already exists"
USER CREATION FAILED : If the new user rules are not satisfied at the backend service and it throws an error then the http status code of 400 can be used and functional status in response payload of "User creation failed, please conform to the user name rules" https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/400
For an API Consumer to know everything about your API's, you may want to provide a API specification document. You may use open API spec(previously known as swagger) https://swagger.io/specification/

Somehow I want the API consumer to know what kind of json structure to handle and i guess the http status code helps for that ?
Not quite.
The HTTP status code is meta data in the transfer documents over a network domain. It communicates the overall semantics of the response (for instance, is the body of the message a representation of a resource, or a representation of an error? is this response cachable? and so on).
For unsafe requests in particular, cache invalidation is sensitive to "non-error status codes". The difference between 303 (non-error status code) and 409 (error status code) can be significant.
The Content-Type header gives you a mechanism to describe the kind (schema) of the message you are returning (ex: application/problem+json).
The way I think about it: the information for your bespoke consumer belongs in the message-body; we lift data from the message-body to the HTTP metadata so that general-purpose components can take advantage of that information (for example, by invalidating cache entries).
So we would normally start by defining the schema and semantics of the message body, and making sure that we have intelligent ways to communicate all of the things we want the caller to know. In other words, we are defining the documents that we pass to the client, and how to extract information from them.
Information that HTTP components need to know get copied from our bespoke document into the standardized forms (status code, headers).
Where things get complicated: the fact that something is an "error" in your domain, that doesn't necessarily mean that it should also be considered to be an "error" in the transfer of documents over a network domain.
A common case: we are using our API to navigate some work through a process; that process has a happy path, and also some exceptional paths that we normally try to avoid (accounts are overdrawn, items are out of stock, etc).
An HTTP request can move work from the happy path to an exception path and still be a "success" in the transfer of documents domain.
The easiest heuristic I know is to think about previously cached copies of responses by the same target URI. If those responses are still re-usable, then you are probably looking at a 4xx status code. If the responses should be invalidated, then you are probably looking at a 2xx or 3xx status code.

Which http status code is suitable for when request data is correct and response data is not proper

I have situation where request syntax and data is proper and the data received from database is not in expected format - its a case of response data issue - In this scenario what is the suitable http status code.
Thought to use 422 - Unprocessable entity - its more on request body validation - please suggest
Thanks

Probably Internal Server Error(500) as the error is occurring on the server end.
4XX is only for client-side errors.

I like to think in this way;
Can the client(or user) get rid of the problem by himself, like changing request params or syntax? Use 4XX codes
Isn't there anything he can do without contacting support service? Use 5XX codes
In your case I would still think about the scenario;
User is requesting with correct syntax
Data is proper
So why returned data is not in expected format? Then there is a problem while data is being written do DB like missing validations etc. or some bugs exist.

4xx Client Error
The 4xx class of status code is intended for cases in which the client seems to have erred.
So, 4xx codes should be used only for client side errors, in your case, you should use an 5xx error, the best option in your situation is 500
The server encountered an unexpected condition which prevented it from fulfilling the request.
You can see more HTTP Status Codes here

Avoid multiple request java web applicaiton

Third party integration, browser redirection function is triggering multiple request (only IE), 2 requests within 2 nano sec difference. I am using request attribute to deduct duplicate request and processing correct request(first request), duplicate request is sending error message. Unexpectedly, the browser is getting an error on the first request and stops further process(redirect to another component due to error).
Because error response is sending immediately, correct request is taking few nano seconds for processing the business logic.
How can I stop the duplicate request? Can I put Thread.sleep(20 sec) in error request , so duplicate request will be redirected after 20 sec by that time correct request will be processed and redirected to browser.
Is this advisable?

If I understand your question correctly, your problem is : have 2 requests and they send them together to your web application, but 1 of requests got error message.
If it's correct. The solution will be depend on the expected of the client, what's kink of response they expect on this case. We have 2 ways to go :
Return the error message when 1 message have problem to the client
Ignore error request, and send the response for the second request.
In my point of view , don't use this one :
Thread.sleep(20 sec)
What's happen if your request take more than 20 sec to process.
Hope it helps.

REST endpoint returns different results in AWS vs. localhost

EDIT: It looks like my observation that both localhost and AWS were returning 409 was incorrect. AWS is returning 500 (which I would still expect to return null, as the #ExceptionHandler method for Exception.class clearly sets the status to 500 and returns null). Looking closer at the exception message, "could not inspect JDBC autocommit mode; nested exception is org.hibernate.exception.GenericJDBCException: could not inspect JDBC autocommit mode", this is looking more like a database-issue.
ORIGINAL:
I have a RESTful service written in Java/Spring. In this service, I have 3 #ExceptionHandler methods, all of which return null. Only one exception sets the status to 409 Conflict, which is the one I'm expecting in my current scenario.
While testing the service with Postman on localhost, under a particular circumstance, I get an expected 409 Conflict with no data body. However, when I hit the service after being deployed on amazonaws.com, I get the 409 Conflict with a result body consisting of timestamp, status, error, exception, and message values. The version returned by /manage/info looks correct and the git commit data is reported exactly the same.
The localhost version returns 4 headers (plus a custom one):
Content-Length = 0
Date = (today)
Server = Apache-Coyote/1.1
X-Application-Context = application
The Amazon AWS version returns 5 headers (plus the same custom one):
Content-Type = application/json;charset=UTF-8
Date = (today)
Server = Apache-Coyote/1.1
Transfer-Encoding = chunked
X-Application-Content = application, application
What could be causing this? My application calling the service ~could~ handle either situation, but it seems wrong to bandage a fix there when obviously something weird is going on in the service, itself. It was coded to expect null, not a body consisting of values that would not be part of a non-409 result.

What could be causing this?
It is most likely the web-app framework that you are using to run the service. It might be an inherent difference in framework software (on your local machine and AWS), or there could be configuration differences.
(I note that you haven't mentioned how you are running the service locally.)
My application calling the service ~could~ handle either situation, but it seems wrong to bandage a fix there when obviously something weird is going on in the service, itself. It was coded to expect null, not a body consisting of values that would not be part of a non-409 result.
I disagree that there is "obviously something weird" going on. This is the sort of thing that >>I<< would expect if I tried to run a web service on a range of different web platforms. Especially if I was taking a "light touch" approach to configuration / deployment.
You could probably make your local host platform handle error responses more like AWS, and possibly the other way around.
But I think the simple solution is to change the client to work with both kinds of error response.
I think my answer still applies to your updated question. Modify your client code to handle error responses with and without bodies. It is also worth logging the response body for unexpected responses.

HTTP 405 - Method Not Allowed error on a 200 OK response

I have a small REST-ful Java back-end that some clients written in C connect to. There is a certain POST method they call where they send some information, I save that to a database and respond with 200 OK, if all goes well. Basic structure shown below.
#POST
#Path("/mypath")
#Produces("text/html")
public Response processMessage(final String message, #Context final HttpServletRequest request) throws IOException {
.....
return Response.ok().build();
}
My issue is that on this response, I get the following error in the log:
javax.ws.rs.NotAllowedException: No resource method found for , return 405 with Allow header
I understand what this error means in circumstances when let's say you try to execute a GET on an endpoint that is supposed to be a POST, for example. I can't understand though why I would get this after my response goes out, and it clearly shows that the request type is empty.... so odd.
Some additional info - the code on the client side has been buggy with incorrect HTTP code... but what would have to be wrong on the client side to cause this kind of response? (I do not have access to the client side code).
Also, there is no client side code in my app, if you are wondering if there is some other code making a call out of my webapp.
Thanks for any ideas!

The issue is most likely on the client side, so without seeing that code it is difficult to offer more detailed information -- but my expectation would be that this is a result of your client attempting to do something like POST or PUT credentials, or something along that line.
Your only recourse is to enable verbose request logging, log the requests that are generating 405 errors, and report it to the client developers.
Worth noting, however, that any publicly-exposed APIs will generate piles of 405s and 404s because "hackers" will try to execute things like WordPress hacks and so on against any known URL.