Object Notations beyond JavaScript

JavaScript Object Notation is a data interchange format based on a subset of JavaScript. The beauty of JSON is in identifying a subset of language constructs which are safe for data interchange. For instance the following snippet represents a valid JavaScript but it’s unsafe for data interchange and is invalid JSON.

{"body" : "Chunky " + "Bacon"}

On the the other hand, the example below is using String literals is safe for data interchange and is valid JSON.

{"body" : "Chunky Bacon"}

This simple idea goes a long way. Instead of defining our own format for data interchange, we are using subset of a language for exchanging objects by computer programs and since it’s represented in JavaScript, it’s easy for programmers to understand. Once you think about safety, it’s intuitive to see the subset of language constructs useful for data interchange.

The idea behind JSON employing JavaScript is analogous to REST employing HTTP. This makes JSON natural format for RESTful services and typically RESTful services provide data in JSON and XML formats. However, often working with Ruby and PHP, I find neither JSON nor XML, particularly enjoyable for hacking services. I would much prefer REST services data in the native format of language I am working with. From service provider point of view, it’s worthwhile to target other dynamic languages like Ruby, PHP, Python, etc. This leads to the generalization of Object Notations which involves identifying a safe set of language constructs and using them for data interchange. For instance the Ruby and PHP Object Notations for above snippet can be represented as:

Ruby Object Notation:

{:body => "Chunky Bacon"}

PHP Object Notation:

array("body" => "Chunky Bacon")

Service provider who provide formats like XML and JSON,

should also consider other object notations like:

Object notation with padding is the generalization of JSONP where the Object Notation is passed as argument to a specified function which allows programming REST easier than just returning them as values. For RESTful services, JSON and other object notations are better fit than XML. For an example in action, check out http://github.com/rubyorchard/geoip-rest for GeoIP City and Country REST APIs which offer object notation in Ruby, PHP, JSON and XML formats.


2 thoughts on “Object Notations beyond JavaScript

  1. Seems like a good idea. And based on the discussion at #whyday, the different formats might want to follow different conventions. E.g., JSON returns regionName where RBON returns region_name.

    BTW, I imagine this is why Ruby 1.9 supports hashes in JavaScript syntax–so JSON will work seamlessly. Unfortunately it doesn’t go far enough. It supports {body: “Chunky Bacon”} but not {“body”: “Chunky Bacon”}.

    • Brian,
      Supporting camel case, pascal case or snake case for keys makes sense for different object notations. Thanks to suggestion and discussion at #whyday, we have started doing it with our services.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

Blog at WordPress.com.

%d bloggers like this: