I have some questions regarding the most appropriate status for each of the following situations:
PUT in URL localhost: 8080 / users / 1 with a JSON without the Id attribute.
PUT in the URL localhost: 8080 / users / 1 with a JSON with Id 2, ie different from what was passed in the
GET in the URL localhost: 8080 / users / search? sex = ABC , ie an invalid sex for the system (correct sex = male or female ).
Perform a POST to persist some new data , however,
Thank you in advance.
Save!
I do not know if the question is relevant given the time that was asked. Anyway, here is my contribution:
The ideal answer would be 400: Bad Request for all the scenarios you presented. I understand that in these cases the client sent an incorrect request to be interpreted by the server.
I'll look into detailing each scenario.
PUT in Object without Id PUT in URL localhost: 8080 / users / 1 with a JSON without the Id attribute.
Inform the error detail of the interface expected by the request. Since you are using the plural of semantics (user s ), you can return the list of registered users. The URL /usuario (singular) without the Id should respond with status 400 and report the problem in detail.
PUT in Object with Id other than parameter
PUT in URL localhost: 8080 / users / 1 with a JSON with Id 2, that is, different from what was passed in the parameter.
In this case, you can take two paths:
GET with invalid parameter GET in the localhost URL: 8080 / users / search? Sex = ABC, ie an invalid sex for the system (the correct one would be sex = male or female).
The same status 400. Inconsistency in the request informing the error detail of the value of the expected parameters.
In this case you could synthesize your URL to localhost:8080/usuarios/?sexo=ABC . Without the word search . This is because the parameters in the URL already connote the search.
JSON POST already with id. Perform a POST in order to persist some new data, but already with the id.
You can deal in the same way as in # 2. Ignore the submitted Id or return the error explaining the inconsistency.
I also suggest setting a domain for the returned errors, for example:
{
codigo: 0001,
mensagem: 'o parâmetro sexo pode receber como valor apenas feminino ou masculino. Corrija a requisição e tente novamente',
status: '400' ...
}
This does not rule out returning the correct HTTP status.
For more information, see this page: link