JSON vs XML vs CSV
These acronyms can sound like an alien language to people learning to become programmers and especially to established old-school green screen programmers (with the greatest respect to my AS400 and iSeries colleagues)
Don’t worry – all these new terms can be totally baffling!
Let’s break them down into simple explanations:
The WEB Browser side
HTML – Not really a Language in the RPG Sense, but it allows data (that is being sent the screen of the web browser) to be defined as certain types – “this is a heading” and “this is an image” and “this is a paragraph” etc. HTML is the common standard that all browsers use to interpret the data that is sent to them from the web server they are connecting to.
CSS – Think of this as a part of the HTML layout. But, it can also be expanded into its owned file and included in the same way an RPG /COPYBOOK is included. The CSS contains its own language format and describes the screen layout in great detail – fonts, colours, positioning, etc
The Web Server
Web servers can run using many different languages, arguably the most common is PHP with logic being written in Java script. Other contenders might be Java, Javascript, Python, Ruby, etc etc
The Webserver does its thing and when it has a page of information ready to share t other world it packages this page up in a format called HTML.
This HTML designs screen layouts and might be more detailed using CSS (it typically is – this page is for example). When you see a webpage that isnt using CSS it’s a classic “oh my god was this page made in the 1990’s?”
Web Servers can also package up big lumps of data in various formats. These lumps of data, and the formatting language that is used to describe that data, also comes in many forms.
- TEXT – We started of sharing data as big long strings of plain text
- CSV – Then we got a bit clever and started adding descriptors like comma seperated, or pipe delimited – main example CSV format
- XML – Then along came XML. This extensible format took that principle a step further and allowed us to be really granular about the data we are sharing. It allowed us to define data types, layouts and some basic logic
- JSON – Then along came JSON – its just like XML really but the layout is slightly different and this means its smaller. JSON data layouts are fast, flexible and add descriptors to explain what the data is that is being transported. This has become the data interchange format of choice.
The Business Server
This is the IBM i System that stores the data that the Web server reads and presents to the Web.
The IBM i Database is typically read by the webserver using SQL – so IBM i LIBRARIES and FILES (TABLES) can be read directly by the webserver, without any need to call RPG programs at all.
But business logic is important right? So the Web server might execute IBM i programs to do some business logic – these programs (called web services) will build a lump of data to pass back to the webserver. This lump of data will typically be formatted in one of the common data layouts just mentioned.
For example – webserver – webservice – ibm i data – JSON
In the real world, this might go like this — The Webserver calls an RPG Webservice saying “get me a list of customers”. The web service is an RPGLE program and it will read various customer tables, perform any filtering or sorting logic and build a packet of data with all those customers in it to return the webserver. This lump of data will be formatted as JSON. The JSON will be returned to the web server along with a SUCCESS or FAIL flag. The webserver will decide what to do with that JSON data – may be an HTML layout? Maybe a PDF? Maybe an email? and then show it to the user’s web browser?
Simple right?
Confusing to people that have never thought about this… but it’s obvious once you get your head around it.
NOTE: Your IBM i server comes with an integrated webserver. These webservers run in IBM i – on the same machine. Just different layers of software. 🙂