[FOLIO-671] Respond with descriptive information in consistent JSON on bad requests and server errors Created: 13/Jun/17  Updated: 03/Feb/21  Resolved: 03/Feb/21

Status: Closed
Project: FOLIO
Components: None
Affects versions: None
Fix versions: None

Type: Task Priority: P3
Reporter: Marc Johnson Assignee: Unassigned
Resolution: Won't Do Votes: 0
Labels: potential-decision
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Relates
relates to RMB-324 No Content-Type for most errors retur... Closed
relates to STCON-18 status (and error, warn?) props for c... Closed
relates to FOLIO-611 Document general-purpose aggregation ... In Progress
relates to FOLIO-1716 Uniquely identify backend API validat... Closed
relates to FOLIO-1965 API design for deletion prevention Closed
Sprint:
Development Team: Core: Platform

 Description   

Use JSON to describe explanations of bad requests or server errors.

Need to decide on what structure to use. It might be the same as the one used for 422 validation errors.



 Comments   
Comment by Heikki Levanto [ 13/Jun/17 ]

Just remember that we can not guarantee that we always return Json structured errors, "connection refused" is a prime example of one where our servers have no control over the message. So the client code must be able to handle plaintext error messages, at least in some way.

Comment by Marc Johnson [ 13/Jun/17 ]

Heikki Levanto

Good point, I agree that the modules have no control over this and the client needs to be able to handle it.

By bad requests and server errors I was thinking about HTTP responses with a status code within the 400 and 500 ranges respectively. In my mind connection refused is a lower level error (I don't know if the javascript surfaces this differently). Are you referring to the same kind of error?

Comment by Heikki Levanto [ 13/Jun/17 ]

I wasn't thinking of any particular error codes. There can be all kind of proxies, load balancers, and firewalls between the client and our server, and each of those can come up with all kind of errors. As long as the client code can somehow handle those, it is OK. It doesn't have to be pretty, but at least the client should not crash and burn - especially if the client is also part of our services.

Comment by Marc Johnson [ 03/Feb/21 ]

Closing as pre-dates the new decision making process and has not progressed

Generated at Thu Feb 08 23:07:30 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.