SOAP vs REST : Day vs Night

YourAPIExpert Essential Series

In a previous article we touched on the two prominent web services standards as we expanded our understanding of APIs.  Volumes of books have been written on both SOAP and REST as the subject is rather extensive but in this article we will focus on a high level overview of both.

This article is part of the  ‘Essentials’ series and focuses on the ground-level understanding required to undertake the journey in to the world of APIs and will through the course of the series build upon your skills and introduce you to core concepts.  This series is intended for people who wish to gain a rudimentary understanding of APIs such as students, new software developers and managers wishing to gain understanding and experience within their team.

For software developers the 90’s were exciting times.  Microsoft had evolved their Windows operating system to a level where it was comfortable to work with and was extensively deployed in business of all sizes.  Their ‘Windows Server’ edition played a pivotal role in the operation of such businesses and many prominent applications from vendors across the globe supported business in its daily quest for productivity and profit.

But there was a looming threat.  Any software developer worth their salt could sense that there was a technology shift in the industry.  If you worked in a software development department of any kind you would have been used to ‘architected’ (really just pie-in-the-sky requirements) solutions coming through to you but it would usually specify the software target, usually a variant of Windows.

One day, instead of the usual checkboxes being ticked, someone scrawled a hand-written ‘web’ on the form.  How does one target the ‘web’, the whole Internet and every single thing using it?  This is 1994 and there are limitations to possibilities.

Event-Driven Application Architecture

Let us take a minute to discuss event-driven architecture.

In systems that are predominantly driven by a user-interface, whether graphical or not, whether on a screen or a hardware device with buttons one usually finds an event-driven architecture behind it.  From a 10,000 feet view it is a relatively easy concept to understand.  Click a button, something happens.  Push a button, something happens.  Move the mouse, something happens.  Hit a key, something happens.  Things generated ‘events’ and by listening to these events (or more accurately, ‘trapping’ these events) one could interact with them and affect their operation.

This, today, is still the fundamental design of Windows, Linux’s multiple X engines such as GNOME and KDE, OSX and mobile apps.

But it is one thing to design an application to make use of the thousands of events per second generated on an operating system and it’s a completely different thing to design an application for the relatively benign world-wide web of 1994.

Application Architecture

To appreciate the difficulties we will take a shallow dive in to application architecture fundamentals.

For very good reason the internal design of an application consists of compartmentalized levels which interact with each other.  It is done for the same reason you don’t keep a can of gas next to an acetylene torch — very bad things will happen.

As a surface-level example, this is the DNA of a four-tier application:

Presentation LayerThis is the visual design.  Commonly referred to as the ‘front-end’, ‘UI’ or graphical layer.  As its name suggests this is the layer the user interacts with.
Application LayerThis layer is a form of ‘programmatic boundary’.  In essence this is where the coding stops since the next layer is visual display elements.  It is also the layer which accepts and sends data to the presentation layer to give and receive information from the user.  Any actions which need to be taken such as transactions, accessing data or making business decisions are passed down to the lower layers.
Business LayerCommonly referred to as the ‘logic layer’ this layer undertakes application logic and business logic according to prescribed rules.
Data Access LayerThis layer facilitates the low-level operations in accessing data from back-end systems such as data bases or other sources.

Next Up: Data Challenges

Pages: 1 2 3 4

Written by YourAPIExpert