Functional programming focuses on computations and aims to minimize mutating states. Functional programming avoids side-effects and changing data as the basis for operations. Many computations that might rely on changing variables and state information in imperative programming, can be described in terms of mathematical computations in functional programming. Functional programming may rely on imperative steps in the implementations, but these imperative actions are ideally abstracted. For example, lets take a simple loop that finds all the objects in an array with a price property under 10. In imperative programming, this would be:

function bestPrices(inputArray){
  var outputArray = [];
  for(var i = 0; i < inputArray.length; i++){
    if(inputArray[i].price<10){
      outputArray.push(inputArray[i]);
    }
  }
  return outputArray;
}

Can you spot the state mutations that we had to induce in this imperative approach? For each loop we had to modify i (increment it) and for each match we had to modify outputArray (push appends a value to it).

Now if we use a more functional approach:

function bestPrices(inputArray){
  return Array.filter(inputArray, function(value){
    return value.price < 10;
  }
}

This code is completely free of side-effects. We simply described the operation in the form of expressions. The underlying implementation hides all the imperative actions necessary to make this work.

Declarative programming is defined as programming in terms of  "what" instead of "how". Functional programming can be categorized as a form of declarative programming since we describe "what" computation should take place with expressions, instead of describing how the computation should be performed in a series of steps as in imperative programming. However, the declarative programming concept goes beyond just functional programming.

One of the central aspects of most applications is persisting data. A core service that most applications provide to users is to be able to store information relating to the use of the application. A social networking application is useless if it can’t actually remember anything about you and your friends. The functional paradigm is limited here, it’s methodology stands in complete opposition to the central goal of the application. Quite simply, applications must deal with mutating states and data. Here we can still apply declarative programming concepts, describing what the data is, instead of how it was created or how we modify it. Perhaps the most critical and invaluable benefit of declarative programming is that the representation of "what" the object implicitly dictates"how" the object is modified . With a declarative approach there is no need for describing how we interact with and modify data, because the structure of the data reveals the how without any further instruction.

JSON provides a great example of declarative programming. JavaScript supports numerous imperative techniques, but JSON is a declarative subset, which precisely defines what an object’s state should be without directions on how to get it there. For example, we could use imperative techniques:

var movie = new Object();
movie.title="Transsiberan";
movie["rat" + "ing"] = 1+2;
movie.setHowLong = function(len){
  this.length = len.trim();
}
movie.setHowLong("2 hours  ");

This representation describes how to build the state of the object, and can be of unbounded complexity, but it is not actually a representation of the final state. Alternately with JSON:

{"title":Transsineran",
"rating":3,
"length:"2 hours"}

The application of the concept of representation implicitly defining the method of modification can be seen here in the simple JavaScript object. The object’s state is observable as a set of properties and we can immediately infer from the presence of these properties how we modify the objects. We can simply set one of the existing properties to modify the state, and the effect of setting a property is obvious. Conversely, when an imperative approach where opaque object methods are used to modify an object’s state, the effects are not inferrable, one has to refer to out-of-band documentation to understand the interaction necessary to cause a state change.

The other central concept of a declarative approach to data is reversibility . If we modify the state of this movie object, there is a clear unambiguous easily computable representation for the new state of the object with a declarative definition. However, this is not true with the imperative definition. With the unbounded complexity possibilities of the imperative representation, it is impossible to always know exactly when step in the directions needs to modified to correspond the state change.

Another example of declarative programming is HTML. HTML represents the state of the layout of the page. The steps for how to get into a particular layout are not described, the layout is a state that is represented by the HTML. HTML provides clear reversibility as well. Layout changes can be clearly and directly mapped to changes in the HTML representation.

Applications themselves are a form of state as well, both at the low level (code is occupies memory in the form of binary data) and at the high level in languages that reify code. JavaScript is an example of an language where code is data. Here as well, we can benefit from code being organized in declarative approach rather than an imperative approach. An application runtime state that is the result of confusing imperative steps is much more difficult to debug than application that has a clear declarative organization.

Furthermore, declarative programming can often allow programmers to work within a "live" interactive environment, where code can be changed on the fly without requiring a restart. Imperative programming often means that the only way to predictably see the effect of a change in imperative code is to restart. We certainly want to be able to move towards faster development techniques that aren’t stuck in windows-style "restart" cycles.

Once again, declarative programming can be built on imperative programming. If strict discipline of rules is applied to imperative steps, the consistency can yield an declarative form in the context of rules. For example, if we said that all class declarations must take the form assigning a constructor function to a variable and then assigning an JSON object to the constructor’s prototype, then within the context of these rules, we can have a reversible representation that still be used even if we change the state of the class (changing method implementations for example).

It is important that these principles be used to direct our continuing evolution of JavaScript. Techniques like pseudo-classes based on the side-effects within constructor function execution are a regression in the evolution away from imperative to declarative. Prototype-based inheritance does a great job of maintaining declarative programming, as the application itself can be continually updated in interactive code. Debugging can be "live", classes can be evolved without requiring environmental restarts.

function parseJson(jsonText){
  return eval('(' + jsonText + ')');
}

One of the most oft-desired data type that JSON doesn’t provide is a date type. Numerous creative, bizarre, weird, and silly techniques have been proposed for expressing dates in JavaScript. These methods often require extra parsing or walking strategies. Douglas Crockford’s reference library for JavaScript JSON serialization, serializes dates to strings by ISO format. I have written about deserializing these ISO dates. But, on deserialization it is not possible to determine if a value is actually a string or is really intended to be an actual date object. However, if the recipient of JSON is known to support full JavaScript evaluation (like the browser with a library using an eval), the solution for delivering date type value is simple, we can just use the normal JavaScript constructor:

{"mydate":new Date(1222057313264)}

There are also several numeric entities that JavaScript provides that are not available, including Infinite, -Infinite, and NaN. I am not sure why you would need it, but undefined can also be transferred with JavaScript. Functions can be included as well:

{
  "reallyBig": Infinite,
  "parsedString": NaN,
  "whatValue?": undefined,
  "doSomething":function(arg){return doSomethingElse{arg};}
}

The data representations thus demonstrated are not JSON, they are JavaScript using the same object/array literal that JSON is based on. However, certainly one of the biggest benefits of JSON is it’s interoperability. If your data is going to be consumed by more than just JavaScript-parsing JavaScript libraries, you must make your data available in pure JSON format as well. This is well-handled through content negotiation. If you are using JavaScript expressions to transfer data, you should make sure your requests from the browser actually are specifying they can handle JavaScript:

Accept: text/javascript

Your server should be prepared to handle requests from clients that indicate that they only understand pure JSON:

Accept: application/json

Persevere, the JavaScript/JSON application and storage server, also provides support for parsing and storing extra constructs including non-finite numbers (NaN, Infinite), functions. Persevere can output the data as JSON or JavaScript (expression).

JSON is certainly powerful, expressive data format. This post is by no means an attempt to expand or lobby for the modification JSON. However, when it is known that consumers are actually JavaScript capable clients, it can often be advantageous to use the full power of JavaScript to represent data, while still providing JSON as representation for non-JavaScript capable clients.

One of the most important keys to positive successful standardization is not to prematurly standardize on new inventions . Fortunately RESTful JSON is not a new invention, and implementations have forged the way of leveraging and interpreting existing standards and creating conventions as necessary. Any standardization should stand on the shoulders of these efforts. Initial attempts at CRUD-style JSON-based interaction were quite inventive, but inventiveness is not the friend of interoperability when standards already exist (de facto or formal), and HTTP provides a comprehensive set of mechanisms for data interaction. For many forms of data interaction, the intuitive combination of JSON and HTTP provides a high level of power. Many JSON-REST implementations mostly follow the HTTP specification, and often multiple implementations share common conventions. The notes in this post are based on the behavior of server implementations of JSON REST including Persevere , CouchDB , GrassyKnoll , Amazon S3, and RoR’s ActiveResource , and on client implementations including Dojo , Jester , and Persevere JavaScript client .

Another key aspect to establishing a JSON REST protocol is to properly define and distinguish the orthogonal concerns involved. Basic JSON interchange using REST is actually well-specified in the HTTP, but applications often want higher level constructs for effective interaction. Various applications need different features, and they should be able to retain maximum simplicity without overhead from unnecessary constructs. Some of JSON protocols are certainly not specific to RESTful usage. Here is how I would characterize the different components that may be of interest to different RESTful JSON applications:

• Object identity to URL mapping - This is the critical protocol necessary for allowing JSON messages to contain object/sub-resources that can be addressed through REST verbs with URLs. A convention is necessary for determing how any given object is mapped to a URL. Every JSON REST implementation that I am aware defines an identity property and uses that identity to map to URL in the form:

  /table/id

  Or tableless stores will just do:

  /id

  It is certainly possible to create more sophisticated URL mapping schemes with multiple identity properties and alternate URL forms. Most simplicity driven JSON advocates would and probably should reject such complications.

• Data structure definition - JSON Schema seems to be emerging as the protocol for defining JSON structures.
• Service advertising - This defines a protocol for the a server to advertise it’s services. Service Method Description builds on JSON Schema to do this effectively for JSON services.
• Topology - Plain JSON is composed of simple directed object graphs. Applications that need more sophisticated property linking can utilize JSON Referencing for cyclic and cross-domain references. It should be noted that JSON Referencing is an exercise in minimal inventiveness as well, it is basically an application of the hyperlink/relative URL scheme to JSON data. Existing standards are leveraged.

Of course these protocols are not completely orthogonal, JSON Referencing also utilizes object identities, and anticipates RESTful URLs for cross-site referencing lookups. JSON Schema can leverage referencing for describing sophisticated data structures, and can itself define identity properties.

I certainly would be happy to see these protocols standardized. However, my main concern is that a new uber protocol that invents a new techniques for all these concepts, and creates divergence between RESTful JSON usage and other JSON usage doesn’t seem like it would be good for the community. Simply taking a single example use case and lumping all of the needs into a single specification is certainly not a wise course. And most importantly standardizatin of RESTful JSON should be stand on the work of the current implementations, not invent new wheels and contradict the work and conventions that are currently in use today.

Another important concern is that a RESTful JSON protocol should not add signficant complexity. Complexity may be acceptable in other realms, but JSON pioneers have rightly fought for keeping things simple. RESTful web services should be able to simply provide data in the form that it exists. For example if I want to return a set of users, it should be as simple as returning:

[{"name":"Kris", "gender":"male", "id":"1"},
{"name":"Nicole", "gender":"female", "id":"2"}]

A RESTful JSON protocol is not the place to force developers to wrap everything in envelopes or force extraneous additional metadata in objects.

Finally here is a simple example of combining HTTP REST with JSON Schema providing comprehensive data structure knowledge for full interaction:

Here is an example of we have been doing it:

GET /Trail

response:
{
    name:"A database of trails",
    properties:{
        name:{type:"string"},
        description:{type:"string"},
        id:{type:"string",unique:true},
        length:{type:"number"},
        ...
    }
}

And then getting an object:

GET /Trail/3

response:

{
    id:"3",
    name:"Wasatch Crest Trail",
    description:"Follows the ridgeline of the Wasatch mts",
    length:3,
...
}

Likewise we can intuitively PUT or DELETE to /Trail/3.

I hope we can together make progress towards a standard RESTful JSON protocol that is useful for the community, but I believe this can only be done if we keep things simple and build upon what has been done by existing implementations. I believe we have a great foundation for future progress.