Picking HTTP status codes for errors from REST-ful services -


when client invokes rest-ful service, needs know if response came 'from me' or rather diagnosis containing web server awful happened.

one theory that, if code called, should return http ok(=200), , errors i've got return should represented in data return. after all, it's code gets response, not naked browser.

somewhat self-evidently, if i'm using rest generate html read directly browser, absolutely must return error code if there's error. in case care about, it's javascript or java interpreting entrails of response.

another possibility there family of http status codes return high confidence it/they never generated problem in surrounding container. case?

i use following:

get

  • 200 ok
  • 400 bad request (when input criteria not correct)

post

  • 202 accepted (returned authorization method)
  • 401 unauthorized (also returned authorization)

  • 201 created (when creating new resource; set location header)

  • 400 bad request (when data creating new entity invalid or transaction rollback)

put

same post

  • 201 ok
  • 400 bad request

delete

  • 200 ok
  • 404 not found (same get)

Comments

Popular posts from this blog

c# - how to write client side events functions for the combobox items -

exception - Python, pyPdf OCR error: pyPdf.utils.PdfReadError: EOF marker not found -