Last post May 18, 2017 05:29 PM by kmcnet
May 15, 2017 08:10 PM|kmcnet|LINK
Hello everyone and thanks for your help in advance. I am developing a WebApi2 application that returns many dates with the JSON data. This data will be consumed by various applications over differing technologies. For example, one application might simply
retrieve the data to simply display, so the returned data would reasonably be in mm/dd/yyy format. However, other applications might actually need to perform comparisons or calculations, either client side, or server side. I want to know what is the best
practice to provide the widest flexibility for the consumer of the api. Do I return on field formatted and another raw data? Any help would be appreciated.
May 15, 2017 08:44 PM|PatriceSc|LINK
The usual approach is to use "native data" as long as you can and to convert them to a string just before showing them to user. For example you can't even do a date comparison if you expose that as a mm/dd/yyyy string. Similarly it will be a nightmare if
you ever have someone that want to show this date using its own local convention etc... Would you do that for numbers? If not why to do that for dates?
May 15, 2017 08:49 PM|kmcnet|LINK
Thanks for the response. I understand exactly what you are saying, but would you please provide a few examples? For example, in a native datatype for datetime, would you simply return whatever is stored in the datetime column in the database, or would
some reprocessing be required? Then, let's assume an application using jQuery is the receiving application. I'm not really sure how this would be reformatted to a readable format.
May 15, 2017 09:13 PM|PatriceSc|LINK
I would just let the default formatter do its stuff. And so on the client side it should be a date. I would then use my own function or
http://momentjs.com/ to format this date when I need to show it.
IMO it should feel more natural and expected compared with having to convert back a string to a date when you want to do even just a comparison or any other date operation.
In short the idea is would be to expose "data" rather than "display strings" exactly as you likely expose data coming from a db using their "native" type rather than as already formated strings.
I believe you can configure a formater to expose dates differently with a single code change if really needed but I would likely do that if I'm 100% sure on the other side it will be NEVER needed to convert back those strings to actual dates (which is difficult
May 18, 2017 05:29 PM|kmcnet|LINK
Thanks so much. This solutions works like a charm. I appreciate it.