1

In SlashDB, whenever a pass-through query can be executed, the HTTP code returned is always in the 200-class (OK, Created, etc.). Unfortunately, this doesn't account for cases when an error should be returned, such as: item doesn't exist in a table, etc.

Is it possible to force an error code from a pass-through query?

UPDATE: I understand it is a an interminable debate whether a valid query should return an error code if it returns an empty set. There are valid arguments on both sides. I happen to think that if we think, say, a serial number is a resource and it doesn't exist, the call should return an error. Some details can then be placed in the response body as to how to further process the problem.

This question is not an attempt to seek answer to the aforementioned debate, but merely trying to discover whether there is a way in SlashDB to affect the HTTP error codes when using the SQL Pass-thru feature.

2 Answers2

0

It's debatable if a query returning no rows is an error condition that would warrant a 404 Not Found. SlashDB behaved that way in earlier versions, but many developers complained.

Now, as long as the query is valid and executes without issues you will get a result and a 200 OK. It can be an empty list i.e. [], if there are no rows matching your query conditions.

Other error codes can be returned too. For example you will get a 403 if you don't have permissions.

Generally HTTP codes in the 4xx series indicate there's something wrong with a client's request. Codes in the 5xx series indicate some unexpected condition with the server i.e. database is down or time out from heavy traffic.

If this explanation does not address your particular query, please update your question with the query example and pertinent information about your database schema.

Victor Olex
  • 1,458
  • 1
  • 13
  • 28
0

There doesn't seem to be a way to handle this in SlashDB. My solution to this is to declare an error on the MySQL side and a message_text to describe the problem. Because of this error, SlashDB returns an ambiguous 500 code.

It's a brute force solution, but it eliminates the ambiguity for now.