I'd typically consider such a thing as 200 with a response that includes some sort of error/exception code/explanation. The thing already exists, but the request was received, processed, and responded to appropriately. This should be a part of your contract design for the API itself. I personally believe that something that is data related shouldn't return http code other than success. Perhaps adoption of 201 as successful creation/allocation and 200 as non-error without creation having occurred.
I haven't considered using 200 before for valid requests that can't be processed. But it does make sense. I've typically used: 200 OK (for getting valid resources, and for resource deletions), 201 for resource creation, 404 for invalid resource ids or missing routes, and from there I just imagined that a 4XX code would be used to indicate that the request was functionally invalid.
This was based on seeing some consumers of APIs where in python they would do "response = requests.get(...)" and then check if the response is "ok" by using "if response.ok: ...". So that in that case 2XX is ok, and anything else is not ok, so one would expect the failed resource to be in the "not ok", so not a 2XX. But this was just extrapolation. Maybe it is better for all valid requests to be 2XX, but would require more client side logic.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I'd typically consider such a thing as 200 with a response that includes some sort of error/exception code/explanation. The thing already exists, but the request was received, processed, and responded to appropriately. This should be a part of your contract design for the API itself. I personally believe that something that is data related shouldn't return http code other than success. Perhaps adoption of 201 as successful creation/allocation and 200 as non-error without creation having occurred.
I haven't considered using 200 before for valid requests that can't be processed. But it does make sense. I've typically used: 200 OK (for getting valid resources, and for resource deletions), 201 for resource creation, 404 for invalid resource ids or missing routes, and from there I just imagined that a 4XX code would be used to indicate that the request was functionally invalid.
This was based on seeing some consumers of APIs where in python they would do "response = requests.get(...)" and then check if the response is "ok" by using "if response.ok: ...". So that in that case 2XX is ok, and anything else is not ok, so one would expect the failed resource to be in the "not ok", so not a 2XX. But this was just extrapolation. Maybe it is better for all valid requests to be 2XX, but would require more client side logic.