Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.
I am creating a package to work with a rather difficult API, which also has as a rule, (not always) to return a 200 status to everything that is sent, including when there is an error, instead of using the correct HTTP Response code.
Instead send the response without data, and in the metadata change the status to 0, and the reason indicates the error (string)
In my opinion, the correct thing is that my package returns an appropriate HTTP response code to the error (easier to manage for those who use the package and closer to the reality of a Restful API) and leave the error management to the user's hand when you receive the json response with the code and your message.
But when I see it, I see that the response that Guzzle sends me does not contain setters to modify the status. So I have to create an HTTP response.
How can I generate that response, containing the status code? What would be the way?
I must be work with use Illuminate\Http\Response;?
I think this a correct solution
use Illuminate\Http\Response;
...
if ($metadata['metadata']['result'] == 0) {
return response()->json($metadata['metadata'])->setStatusCode(Response::HTTP_CONFLICT);
}
or
if ($metadata['metadata']['result'] == 0) {
return response()->json($metadata['metadata'], Response::HTTP_CONFLICT);
}
@abkrim both look correct, if the status code you are returning matches :)
@abkrim Just as using a 200 OK for every response is problematic, so is using the wrong status code for scenarios.
A Conflict response is for use with preventing updating stale resources; not a generic error status.
@martinbean In this case, the answer is like this, because there are only two positions. A single failure determined by an attempt to create a user with a domain, which is not possible. Therefore, in this one case I return 409 Conflict (en-US)
Which would be the most appropriate according to your experience?
A 406 For example?
@abkrim So perhaps 422 (same as laravel uses for validation errrors). "Sorry that domain is taken. Please contact Liam Neeson"
https://laravel.com/docs/8.x/validation#quick-xhr-requests-and-validation
@Sinnbeck Uhm.. I don't like use 422.
422 Unprocessable Entity (WebDAV) The request was well-formed but was unable to be followed due to semantic errors.
In my opinion, it is not very accurate. At least what I understand about my poor English.
But thanks, I'll go over the Laravel usages with the status codes.
@abkrim It is in the docs. I added a link :)
@abkrim A 409 Conflict has a very specific meaning. Again, it’s for if you try and update a resource that has since been updated. A 409 is used to say, “Your updates weren’t applied because they would overwrite someone else’s.”
Again, using wrong status codes is just as bad as just using a 200 OK for everything. So my advice is, stop overthinking this and just use the status codes as they’re commonly used: if you have a validation error then return a 422 response like Laravel itself does.
Please or to participate in this conversation.