JSON The Fat-Free Alternative to XML { “Lecture”: 27, “Course”: “CSC375”, “Days”: ”TTh", “Instructor”: “Haidar Harmanani” } JSON as an XML Alternative • JSON is a light-weight alternative to XML for data- interchange • JSON = JavaScript Object Notation – It’s really language independent – most programming languages can easily read it and instantiate objects or some other data structure • Defined in RFC 4627 • Started gaining tracking ~2006 and now widely used • http://json.org/ has more information JSON as an XML Alternative • What is JSON? – JSON is language independent – JSON is "self-describing" and easy to understand – *JSON uses JavaScript syntax for describing data objects, but JSON is still language and platform independent. JSON parsers and JSON libraries exists for many different programming languages. • JSON -Evaluates to JavaScript Objects – The JSON text format is syntactically identical to the code for creating JavaScript objects. – Because of this similarity, instead of using a parser, a JavaScript program can use the built-in eval() function and execute JSON data to produce native JavaScript objects. Example {"firstName": "John", l This is a JSON object "lastName" : "Smith", "age" : 25, with five key-value pairs "address" : l Objects are wrapped by {"streetAdr” : "21 2nd Street", curly braces "city" : "New York", "state" : "NY", l There are no object IDs ”zip" : "10021"}, l Keys are strings "phoneNumber": l Values are numbers, [{"type" : "home", "number": "212 555-1234"}, strings, objects or {"type" : "fax", arrays "number” : "646 555-4567"}] l Aarrays are wrapped by } square brackets The BNF is simple When to use JSON? • SOAP is a protocol specification for exchanging structured information in the implementation of Web Services. • SOAP internally uses XML to send data back and forth. • REST is a design concept. – You are not limited to picking XML to represent data, you could pick anything really (JSON included). JSON example { "firstName": "John", "lastName": "Smith", "age": 25, "address": { "streetAddress": "21 2nd Street", "city": "New York", "state": "NY", "postalCode": 10021 }, "phoneNumbers": [ { "type": "home", "number": "212 555-1234" }, { "type": "fax", "number": "646 555-4567" } ] } JSON to XML <?xml version="1.0" encoding="UTF-8"?> <persons> <person> <firstName>John</firstName> <lastName>Smith</lastName> <age>25</age> <address> <streetAddress>21 2nd Street</streetAddress> <city>New York</city> <state>NY</state> <postalCode>10021</postalCode> </address> <phoneNumbers> <phoneNumber> <number>212 555-1234</number> <type>home</type> </phoneNumber> <phoneNumber> <number>646 555-4567</number> <type>fax</type> </phoneNumber> </phoneNumbers> </person> </persons> JSON vs XML size • XML: 549 characters, 549 bytes • JSON: 326 characters, 326 bytes • XML ~68,4 % larger than JSON! • But large data set is going to be large regardless of the data format you use. • Most servers gzip or otherwise compress content before sending it out, the difference between gzipped JSON and gzipped XML isn’t nearly as drastic as the difference between standard JSON and XML. JSON Values • JSON values can be: – A number (integer or floating point) – A string (in double quotes) – A boolean (true or false) – An array (in square brackets) – An object (in curly brackets) – null Why JSON? • For AJAX applications, JSON is faster and easier than XML • Using XML – Fetch an XML document – Use the XML DOM to loop through the document – Extract values and store in variables • Using JSON – Fetch a JSON string – eval() the JSON string Security problems • The eval() function can compile and execute any JavaScript. This represents a potential security problem. • It is safer to use a JSON parser to convert a JSON text to a JavaScript object. A JSON parser will recognize only JSON text and will not compile scripts. • In browsers that provide native JSON support, JSON parsers are also faster. • Native JSON support is included in newer browsers and in the newest ECMAScript (JavaScript) standard. JSON vs XML • Favor XML over JSON when any of these is true: – You need message validation – You're using XSLT – Your messages include a lot of marked-up text – You need to interoperate with environments that don't support JSON • Favor JSON over XML when all of these are true: – Messages don't need to be validated, or validating their deserialization is simple – You're not transforming messages, or transforming their deserialization is simple – Your messages are mostly data, not marked-up text – The messaging endpoints have good JSON tools JSON Schema • Describes your JSON data format • http://jsonschemalint.com/ • http://json-schema.org/implementations • http://en.wikipedia.org/wiki/JSON#Schema_and_M etadata JSON vs XML • "Some people, when confronted with a problem, think "I know, I'll use XML." Now they have two problems. " • "XML is like violence. If it doesn't solve your problem, you're not using enough of it. " • "I use JSON unless I'm required to use XML. " • " I don't hate XML and I don't find it frustrating. I sure as hell hate people that try to solve every problem in the world with XML. " Evaluation • JSON is simpler than XML and more compact – No closing tags, but if you compress XML and JSON the difference is not so great – XML parsing is hard because of its complexity • JSON has a better fit for OO systems than XML • JSON is not as extensible as XML • Preferred for simple data exchange by many • Less syntax, no semantics • Schemas? We don’t need no stinkin schemas! • Transforms? Write your own. • Worse is better #mongodb MongoDB Modified from slides provided by S. Parikh, A. Im, G. Cai, H. Tunc, J. Stevens, Y. Barve, S. Hei History • mongoDB = “Humongous DB” – Open-source – Document-based – “High performance, high availability” – Automatic scaling – C-P on CAP Motivations • Problems with SQL – Rigid schema – Not easily scalable (designed for 90’s technology or worse) – Requires unintuitive joins • Perks of mongoDB – Easy interface with common languages (Java, Javascript, PHP, etc.) – DB tech should run anywhere (VM’s, cloud, etc.) – Keeps essential features of RDBMS’s while learning from key-value noSQL systems Design Goals • Scale horizontally over commodity systems • Incorporate what works for RDBMSs – Rich data models, ad-hoc queries, full indexes • Move away from what doesn’t scale easily – Multi-row transactions, complex joins • Use idomatic development APIs • Match agile development and deployment workflows Key Features • Data stored as documents (JSON) – Dynamic-schema • Full CRUD support (Create, Read, Update, Delete) – Ad-hoc queries: Equality, RegEx, Ranges, Geospatial – Atomic in-place updates • Full secondary indexes – Unique, sparse, TTL • Replication –redundancy, failover • Sharding –partitioning for read/write scalability MongoDB Drivers and Shell Drivers Drivers for most popular Java Ruby programming languages and frameworks JavaScript Perl Python Haskell > db.collection.insert({product:“MongoDB”, Shell type:“Document Database”}) > > db.collection.findOne() Command-line shell for interacting { “_id” : ObjectId(“5106c1c2fc629bfe52792e86”), “product” : “MongoDB” directly with database “type” : “Document Database” } Getting Started with Mongo Installation • Install Mongo from: http://www.mongodb.org/downloads – Extract the files – Create a data directory for Mongo to use • Open your mongodb/bin directory and run the binary file (name depends on the architecture) to start the database server. • To establish a connection to the server, open another command prompt window and go to the same directory, entering in mongo.exe or mongo for macs and Linuxes. • This engages the mongodb shell—it’s that easy! MongoDB Design Model Mongo Data Model • Document-Based (max 16 MB) • Documents are in BSON format, consisting of field- value pairs • Each document stored in a collection • Collections – Have index set in common – Like tables of relational db’s. – Documents do not have to have uniform structure JSON • “JavaScript Object Notation” • Easy for humans to write/read, easy for computers to parse/generate • Objects can be nested • Built on – name/value pairs – Ordered list of values BSON • “Binary JSON” • Binary-encoded serialization of JSON-like docs • Also allows “referencing” • Embedded structure reduces need for joins • Goals – Lightweight – Traversable – Efficient (decoding and encoding) BSON Example { "_id" : "37010" "city" : "ADAMS", "pop" : 2660, "state" : "TN", “councilman” : { name: “John Smith” address: “13 Scenic Way” } } BSON Types Type Number Double 1 String 2 Object 3 Array 4 Binary data 5 Object id 7 The number can Boolean 8 Date 9 be used with the Null 10 $type operator to Regular Expression 11 JavaScript 13 query by type! Symbol 14 JavaScript (with scope) 15 32-bit integer 16 Timestamp 17 64-bit integer 18 Min key 255 Max key 127 http://docs.mongodb.org/manual/reference/bson-types/ The _id Field • By default, each document contains an _id field. This field has a number of special characteristics: – Value serves as primary key for collection. – Value is unique, immutable, and may be any non-array type. – Default data type is ObjectId, which is “small, likely unique, fast to generate, and ordered.” Sorting on an ObjectId value is roughly equivalent to sorting on creation time. MongoDB vs. Relational Databases Why Databases Exist in the First Place? • Why can’t we just write programs that operate on objects? – Memory limit – We cannot swap back from disk merely by OS for the page based memory management mechanism • Why can’t