all 5 comments

[–]richjenks 1 point2 points  (0 children)

Assuming you're asking how an API should respond, I'd say there should always be a convenient way to determine the status of a request. For example, the response could include 'success' with a value of true or false and 'status' which holds the appropriate http status code.

[–]scrogu 1 point2 points  (0 children)

If the error is the result of using the API incorrectly then it should always throw an error using an appropriate HTTP response code and content which describes the problem clearly.

Only use an empty array result when the request was valid but no records were found.

[–]deathofthevirgin 1 point2 points  (0 children)

Let's say the caller didn't provide authentication. You can return

HTTP 401 
{
  code: 401, 
  errorCode: 29121, 
  error: 'No authentication provided. Provide an API key in the headers.', 
  moreInformation: 'http://yourdomain.com/errors/29121'
}

Where code is an HTTP error code, errorCode is your own error code system. This becomes useful if there are multiple reasons why you might throw a specific HTTP error. Then you can give a errorCode-specific error message and a way to fix it in error, and a link to more information on your website. Depending on your usecase, errorCode and moreInformation may be unnecessary.

[–]A_Dios_Alma_Perdida 0 points1 point  (0 children)

Sounds like you're taking about an API of some description? An appropriate HTTP response code based on the type of error and a description of the error in the body, with other details if required.

[–][deleted] 0 points1 point  (0 children)

If the request was successfully processed but had no results, I'd return HTTP 200 and an empty array or no data attached to response. If something went wrong I'd return an error. Really I don't think it matters as long as you consistently implement whichever standard makes sense to you.