How to get to grips with the FileMaker Data API for FMS 17

We are working on the FileMaker Data API for FMS 17 and struck a couple of problems on the way with numbers and layouts. So, we thought we’d share our findings, in the hope that it will help someone else avoid the same problems we had.

This development environment is currently hosted on FMCloud 1.17. We are using Postman as our API development environment. We found the setup, scripts and authentication process straight forward to implement using the FileMaker documentation, however, this guide from is also worth a look.

Issues with numbers

The system we want to interrogate has a number of long number UUID fields for the primary and foreign keys. We have found that interrogating the API with Postman returns the ID fields as numbers in the JSON but in floating point notation. This seems quite strange, and makes integrations more challenging. We have been through the layouts (as the API is controlled by the fields on the layouts) and extended the field sizes and also the Data Formatting of those fields. However these changes have not made any difference.

We are using number fields to minimise the Index as the solution is already quite large, but, as a workaround, we could create additional fields that render the IDs as text (JSON string).

Further investigation

FMS17 Data API returns some varied results and seems to do its own thing once the ID gets over a certain length BUT it does return the data as per the field TYPE, when the contents of that field match the type:

ID is a number Field. IDtext is the same data stored as Text.

Record 1 = String as value contains text values. The number field contains text returned as a String so is quoted.

Record 2 = Number hasn’t changed and is not re-formatted.

Record 3 = Number BUT is reformed with a floating point.

The solution

Almost frustratingly, we were able to “solve” this without a work around. It turns out that Postman, when making the results look ‘pretty’, changes the number formatting. When viewing the Raw results, the numbers are displayed as expected.

Note: FileMaker will also change how the number is displayed when using JSONFormatElements (json). However, it seems that it is not just the display. When using JSONGetElement(json;keyOrIndexOrPath) the result returned will contain the floating point (if the number is big enough).

So, although the Data API is working as expected, we may need to account for longer numbers in JSON and should possibly look at setting the number as JSONString.

Results with problem

Issues with layouts

After initially saying the setup was smooth, we did encounter a problem when we tried to GET records from some layouts.

During setup, to help make sure we got the expected results we were using a GET request: /fmi/data/v1/databases/database-name/layouts/layout-name/records

Most of the time, this was fine. We occasionally received an error though:

{“messages”:[{“code”:”105″,”message”:”Layout is missing”}],”response”:{}}

In this case, the layout name was ‘apiJobs’, so the request was to /fmi/data/v1/databases/database-name/layouts/apiJobs/records

The layout definitely existed so why wasn’t it working?

Here is the layout name.

apiJobs

There are no spaces and nothing hidden. Trying ‘apiJob’ would work and ‘apiJobs2’ would also work.

Having searched the forums and the internet, and not being able to find a solution, it was time to move on. The layout was renamed, the request worked and the development continued.

It was only when tidying up on ‘Manage Layouts’, changing folder names for a consistency, that the cause was identified.

The solution

Do not have folder names that are the same as layout names! Simple when you know that answer. It’s one of those things that now we know, we won’t (shouldn’t) get caught out again.

It does only seem to be a problem if the Folder was created before the Layout, but knowing the problem now, we will avoid doing that in the future. In this example, there were other layouts and folders within this folder. Having one folder per layout isn’t something we normally do!