RESTfm Returns 500 Error Whne No Records Found

[goyaptyltd]

RESTfm Returns 500 Error Whne No Records Found

[gav-]

I will assume that you mean 404 (Not Found) in place of 401 (Unauthorized) in your comment.

The difficulty here is how to map a search-like function onto a REST-like URL and return an intelligible error code when the URL is correct, but the search returned no results.

A HTTP 404 code cannot be returned in your case as the URL is actually valid. In the case of a URL in the form of http://{server}/RESTfm/{database}/layout/{layout}/{recordId} with a non-existent {recordId} then the result will be HTTP 404.

So returning HTTP 500 and passing the FileMaker response code through as X-RESTfm-FM-Status (in both the HTTP header and in whichever output format you are using) is by design.

[marioantonini]

Just found this question in SO and was thinking that 204 might be appropriate.

[gav-]

At one point RESTfm used 204 in response to DELETE operations, but in trying to support rather limited HTTP clients (like FileMaker itself) that could not differentiate the 2xx return codes, we standardised on 200 for all successful operations.

FileMaker "find" can return many different error responses, only "No records match the request" could possibly map to HTTP 204. Client code must already expect HTTP 500 from RESTfm as an indicator to inspect X-RESTfm-FM-Status for details of the other cases, so there isn't any additional overhead in detecting the simple case for not matching any records (client side).

Thanks for your suggestion, even though we are unlikely to be breaking RESTfm's behaviour now that it's established, it is always worth revisiting some of these points.