CODEWITHSUNDEEP
javascriptjsonrestclient-side
Marian Ban
Marian Ban

Reputation: 8188

Why to use types in JSON responses

I'm working on the front-end of a application which communicates with a back-end thought REST API. The back-end is some kind of standalone device, not a standard web server thus it is not so powerful (but can run php). The API is very generic and returns values like-key value pairs e.g. 

[{ key: "key1", value: "some value" }, { key: "key2", value: "1234" }]

The problem what I'm facing is that it does not consider types, it returns everything like string in quotes (numbers: "123", boolean: "1"). Recently I asked for a change (my argument was that the manual type conversion is unnecessary work which has to be done by each client app and can be avoided if the server can do it) but I need some more convincing arguments. Some counterarguments to my request are:

  1. RESTful communications is natively as a string (so regardless, if transferring a 1 or a "1" -- a client side type conversion has to be done)
  2. it is the responsibility of the GUI designer to understand the context of each parameter
  3. the back-end is following the KISS principle keeping everything as strings and no additional processing is needed on the back-and and can be done on the GUI which is typically on a much more powerful PC

So what could be some good arguments to convince my colleagues that types in JSON responses are good thing for me and for them as well?

Thanks

Upvotes: 2

Views: 208

Answers (2)

MarengoHue
MarengoHue

Reputation: 1825

First of all, the idea of using the following data format [{ key: "key1", value: "some value" }, { key: "key2", value: "1234" }] is kinda stupid and is basically the same as { "key1": "some value", "key2": "1234" }.

In regards to the points, your colleagues made: 1. While this is indeed text-based transfer and conversion between the string representation of your object and an actual object has to be done, there would be no need to recursively walk the tree of key/value pairs if you were to transfer objects or other complex types as values.

Let's pretend that you have to transfer following piece of data:

{ "key1": { "x": 10, "y": 20 } }

if you were to encode inner object as string you would get something like this:

"{ \"key1\": \"{ \"x\": \"10\", \"y\": \"20\" }\" }"

If your value was converted to string, you'd have to call JSON.parse on the entire object first as well as on the object that was possibly stored as text inside that object, which requires recursive walking of the tree. On the other hand, when using native types (such as objects, numbers and arrays) as values you would achieve the same effect with just one call to JSON.parse (which would internally be recursive, but still better that managing it yourself).

Second point is valid but I feel like any service should return the data in ready-to-use form or at least as ready as it can be. Wouldn't it be stupid if your service gave you some piece of raw XML instead of parsed and prepared data? Same principle applies here.

I feel like your friends are just being lazy trying to cover their butts with KISS principle here. It is very likely that their server code has all the info it needs to encode the values in their proper types, which would be much harder to do on the client side. So their third point seems like a blatant 'we are too lazy so you have to do it' thing.

Upvotes: 1

Walfrat
Walfrat

Reputation: 5353

RESTful communcation and JSON are 2 different things. JSON is only the format of the data, it could be XML or even CSV or a custom one, this doesn't remove that RESTful aspect.

JSON is natively handled by pretty much all javascript library that handle server communcation, no parsing to do, little conversion (maybe date object in timestamp and other kind of stuff).

On the server-side there are a lot of library that can handle the JSON for you too, and how they generate the key-value thing ? A generic code with introspection or do they write tons of serializer for all classes ? This can lead to a lot of technical and unncessary code to write, and test.

KISS doesn't mean to keep it totally stupid and don't think about anything. Having boolean has a number in a string and number as string has nothing simple as a developper, it's merely hell to handle for all objects conversion. If you need to check for data constraint, this will lead to a repeat yourself when you will have to validate every fields (testing if the number is a number,...).

The more simple thing is not to write your own library that convert all to string, with probably less performance that specialized library. It's to used library that do the job for you.

If you write all as typed object, your json deserializer on backend will do a part of the validation for you, a boolean will be a boolean, a number will be a number, if you have a lot of validation to do, this lead to way less code to write to perform all the checks.

Client-side i guess there is a lot of code to deal with all this key/value things and to convert values. This slow down development as hell and if you perform unit-testing, it adds lot of testing to do.

it is the responsibility of the GUI designer to understand the context of each parameter

Well this is true, but i feel like providing well formatted data is the responsability of the server. Enforcing a format will lead to a fail fast pratice, which is a good thing. Did they never had any production problem because of this generic format ? They wouldn't with proper JSON.

Personnaly my JSON code on the server is Java annotation and one custom serializer, nothing more. I wonder how much code did they write to serialize/deserialize and convert types.

Upvotes: 3

Related Questions