Clean up error handling in all endpoints

[richardxia]

The error handling in the recently added Bookmarks, Folders, and Saved Search endpoints is fairly inconsistent. A few baseline things that we should do are:

• Make sure that failures actually result in 4xx or 5xx status codes so that API clients are aware that an error occurred
• Make sure client-side errors result in 4xx (usually 400) status codes
• Make sure that server-side errors result in 5xx status codes

[rosschapman]

Please also consider returning 2xxs with clear messaging in cases where data might be missing. For example, for client applications at Exygy, we've tried to access Service data that used to exist but was cached in an Algolia index. The response comes back with headers and no content, which is challenging to parse (in code, and semantically) because it could either suggest there is no data or the url destination is no longer available. For example, if we send a GET to retrieve service data at .../api/v2/services/4178 in a client application and receive the response below, how might we design an accurate error message for the user who's interested in that service?

This service has been discontinued, here are similar services...
There is a problem with our system, please try again...
etc...

HTTP/1.1 404 Not Found
X-Powered-By: Express
Content-Security-Policy: default-src 'none'
X-Content-Type-Options: nosniff
Content-Type: text/html; charset=utf-8
Content-Length: 150
Vary: Accept-Encoding
Date: Wed, 28 Aug 2024 23:51:18 GMT
Connection: keep-alive
Keep-Alive: timeout=5