are the API returning a JSON with data treated as strings even if the field is a number or a date?
Please tell me I'm wrong...
Maybe you just need to wrap the returned JSON results with GetAsNumber() or GetAsDate()?
I'm talking about APIs, so it's FileMaker Server accessed by an external application.
Using parseInt() to transform a string back to a number already requires a bit of work, but dealing with the dates is a LOT of work and I sincerely hope there's an alternative...
APIs are no problem. Dates are a pain in every environment.
Dates are easy to process in any modern programming language. I use Java and JDBC to do any heavy lifting with FMP/S.
With Java 8 , for example, you can easily handle FMP Timestamps returned by SQL, for example. For FileMaker formatted dates, decidedly nonstandard, you can easily define the "format" of the date string you'll use (in Java, as one example).
If you can give me an example, I can help you better.
ric_cosa wrote: Hi everybody, are the API returning a JSON with data treated as strings even if the field is a number or a date? Please tell me I'm wrong... Ric
You're not wrong, FM made the choice to return any and all FM data as string, regardless of the data type of the underlying field.
It's one of the differences vs. the XML API. With the XML api you also get metadata about the fields so you can always figure out what the FM data type is.
Having said that; while I was surprised at first too, I don't really see it as a problem. Chances are that I would be explicitly casting to the right data type in my receiving application anyway to make it safe against changes on the FM side.
Well, I do see it as a problem.
Especially if FileMaker decides to arbitrarily cast a datatype (e.g. a Date) into a String using a non-standard format.
What kind of API, especially if the main target is web oriented, returns a Date in MM/dd/YYYY format instead of ISO8601?
It looks like a poor implementation to me, but if it's documented, we'll see if it's the case to use these API or switch to RESTFm.
Thanks for your help, anyway.
I agree that dates are usually a pain, but returning as strings in a non standard format is not a valid solution...
After Wim post, where it's clear is a made by design, I'll think if stick to native API (that have actually very poor performances on large data sets, btw) or move to something different.
Thanks for your help.
JSON dates are always strings. It’s just that other languages (Swift, etc.) have good support for converting these to date objects.
My guess is that FileMaker chose MM/dd/YYYY to make it easier to use with FileMaker’s existing date functions. I’d rather see 8601 and some new JSON functions to support that. Maybe we’ll get that before the Data API is out of beta(?)
post it here to get up-voted: Product Ideas
That's exactly right.
In Java also you have to coerce the strings to other types.
My guess is that FileMaker chose MM/dd/YYYY to make it easier to use with FileMaker’s existing date functions.
It would be an understandable choice if the typical use case scenario was to use FileMaker API from FileMaker. But I don't think this is the case: 99% of the times, API are going to be used by external, web based applications, that don't have anything to do with FileMaker Date() functions...
I’d rather see 8601 and some new JSON functions to support that.
If what I'm writing above is true, I'm not sure a native FM JSON function could be helpful, in that.
Maybe we’ll get that before the Data API is out of beta(?)
This would be even stranger: they give us a product to test, we change our web apps in order to parse and be able to treat data that the API provide us then, after the release, they change the behaviour?
I'd be rather surprised to see this happens.
ric_cosa wrote: This would be even stranger: they give us a product to test, we change our web apps in order to parse and be able to treat data that the API provide us then, after the release, they change the behaviour?I'd be rather surprised to see this happens.
Let's be clear: that's exactly what they are saying. Nothing about the Data API is set in stone. It's an explicit beta.
Just like with the regular XML API: in those scenarios that you want to have more control then many of us create our own web service as an intermediate so that we can translate and catch changes without affecting the outward facing layer. More work but ultimate control.
Since Data API retruns dates in a string in US format ( I wanted dd/mm/yyyy) I just used the formula :
variable $date (containing the US format from Data API)
Day( $date) &"."& Month( $date) &"."& Year ($date)
It worked for me.
Retrieving data ...