While people grappled with the complexities of SOAP, someone cleverly got the idea of ditching SOAP and keeping messaging. Plain XML in the HTTP body,it turned out,would do the trick . So XML formation and parsing were the only non-trivial computing tasks left out.
I have seen this design type in action in at least two cases: 1. Amber Road 2. Oracle OTM. I am sure there are many more.
It was a good enough solution. But then, humankind has rarely been satisfied with something good enough. So some guys got into the job of replacing XML with something less verbose. The ceremonies of SOAP were to be as little as possible. JSON - Javascript Object Notation - replaced XML and everything suddenly became quite smooth. The resulting architectural style came to be known as REST - acronym for Representational State Transfer. It is not a protocol. It is more of a programming style. The style is simple. Exchange JSON encoded text through the HTTP Body. No pre-defined templates are needed.

So we need to know what this magical entity JSON is. The formal definition that it is a serialized Javascript object won't help much. JSON is more about a theoretical hypothesis that data about any object - however complex - can be represented in terms of a combination of dictionaries and lists. A dictionary is a collection of data elements,each having a unique key attached to it. Something like this:

{ " A ":"Apple", "B":"Bat", "C":"Cat" }

It is quite similar to a real life dictionary.

You may note that a word never repeats. That is also the concept of a "key".
The structural part of a JSON dictionary is probably clear at this point. But what is, I am sure, is not clear is why should an object require a dictionary to be defined?
Well, to this date, we introduce a physical object to a computer using chunks of alphanumeric texts. Not a very efficient way of doing things. But computers understand little more than that!

We have this scenario:

If we store the data in that format, we lose granular access to data. Also, a computer cannot make sense of it, even though an average literate person can. It requires additional data to understand data. And that additional data is metadata.

In our example data, we need six tags or keys or identifiers to make it machine readable. If we follow the JSON convention, we will have something like this:

There may be a situation where you may have multiple values against a single key. Mr. Owen may have two mobile numbers. In such a case, you will use a list:

When you have multiple JSON objects, you can form a list like this: