SOAP vs. REST - a wise guy's view

(I submitted this to Google years ago when applying for a tech writing job. I didn't get the job, but it still gives me laughs to this day. Maybe it will brighten your day, too.)

SOAP vs. REST

A software system that provides machine-to-machine communication via a network is commonly known as a web service.? SOAP and REST are two popular mechanisms used in modern web development to facilitate such communication.? Understanding the differences between the two is best done with a small history lesson.

A bit of history

In the beginning, computers could do a lot of cool things, but the coolness really started to take off when computers began speaking to each other.? Computers speak to each other by virtue of a protocol, which is just an agreed upon standard by which bits and bytes get transferred between two machines.? At first, a computer could only speak to another computer directly connected to it via a serial cable.? Although this primitive form of computer networking allowed our nerd ancestors to chat, play pong, and exchange text files between neighboring cubicles, the management demanded more value-add.

Eventually the modem was born, allowing two distant computers to communicate through the telephone network.? This new freedom allowed primate hackers and computer geeks the ability to exchange ASCII art and pirated “warez” with each other.? More sophisticated protocols were designed to support such information exchange, leading to the development of the Bulletin Board System, or BBS for short.? A BBS is similar to a primitive web server, whereby a user could “dial up” to it using a modem to post bulletins, exchange files, play online games, and send electronic mail (e-mail) to other users.? They could even be used to send instant messages to the system operator (provided he or she was near the console at the time).

Although BBSes were popular, they were not scalable.? As a result, they eventually gave way to their corporate counterparts, CompuServe, Prodigy and AOL.? These behemoths ruled the roost for years, enslaving thousands of dial-up subscribers until Al Gore invented the Internet.? Once the information superhighway was born, the guys at ARPA decided it needed to be paved.? So they created the Transmission Control Protocol/Internet Protocol, more commonly known as TCP/IP.? Connections were no longer point-to-point, as a single computer could send and receive data between multiple computers over the same connection.

This is when computer communication really started to get fancy, as data couldn’t simply mosey along on foot as it had in the good ol’ days of RS-232.? No way!? From this point on, data was to be carried in TCP packets with message headers containing control bits and checksums.? In addition to revolutionary achievements in communications, computers also began to multitask.? This meant that not only could a single computer communicate with multiple partner computers, multiple processes on a single computer could communicate with multiple processes on a remote computer as well!

Running out of things to protest, researchers at Berkeley decided to spend their time creating BSD sockets, a computing library with an application programming interface (API) used to facilitate inter-process communication (IPC).? Not being the types to be one-upped, the engineers at Microsoft created Winsock, a Berkeley sockets clone that marked the beginning of all things that would eventually go wrong in computer networking.? Soon after, they invented DDE, OLE, ActiveX, and COM in efforts to improve inter-process communication and forever ruin buzzword bingo for IT recruiters.

Microsoft wasn’t alone in the quest for standardizing network communication, however, as the open-standards group called Opposing Microsoft Greed (OMG) developed CORBA in efforts to steer the world towards peaceful, unified distributed computing.? Microsoft responded with DCOM, and a battle ensued.? The OMG sent legions of ORBs to fight against the marshaled forces of GUIDs and CLSIDs.? The result was a costly battle that resulted in the world switching from distributed computing to web services.

Enter SOAP

The Simple Object Access Protocol (SOAP), was born as a result of Microsoft’s browser war with Netscape and the desire to move away from the binary bitterness of the DCOM vs. CORBA massacre. ? Having lost their beloved mascot, Microsoft Bob, while fighting Netscape and the OMG, Microsoft decided to switch gears and focus on text-based messaging.

By this time, bandwidth had become cheap, programmers had become expensive, and marketers decided that “the Web” needed to be versioned.? So, instead of transferring small, efficient packets of binary data as they were in the WWW world, the new and improved Web 2.0 moved towards transferring insanely large amounts of human-readable XML (eXtremely Massive Load) files.??

SOAP fits in nicely here because of its dependence upon XML for its message format.? At its core, SOAP consists of three parts:

  • an envelope defining its message structure and how said message should be processed
  • a set of encoding rules
  • a convention for representing procedure calls and responses

A single SOAP message consists of a header and body wrapped within an envelope.? Faults would also be included in the event of an error.? SOAP initially gained traction due to WS-* extensibility, support for any programming model, and its ability to operate over practically any transport protocol.? However, despite toolkit support, developers still found it to be too cumbersome and verbose.? More importantly, developers couldn’t stand being laughed at whenever they had to pronounce WSDL and UDDI during interviews and PowerPoint presentations.

Give it a REST

REST was invented by His Holiness the Reverend Roy Fielding, a self-described California beach bum who eventually became an Adobe-dwelling monk.? Stateless and without any cache, Fielding lived alone with his dog, struggling for years with how to communicate better with the loyal canine.? SOAP was too complex, required a toolkit for his platform of choice, and used too many angle brackets and not enough curly braces.? One night he had a vision, where an angel suggested using basic verbs, sensible resource names, and numeric response codes in order to effect reliable, straightforward communications with his furry pal.??

At first, Fielding tried the following verbs:

SIT, STAY, PLAYDEAD, BARK

but quickly realized that, if he switched to HTTP verbs, he would not only be able to speak with his dog, but with the entire world as well (provided they replied with JSON-based messages, of course).

Drop the acronym, and the SOAP API

REST immediately became a worldwide (web) sensation.? REST not only made it easier to request data via simple URLs, but receiving data through JSON meant that developers could consume more curly brackets than ever before.? Whereas SOAP left a sticky film that never rinsed away, REST left overworked developers feeling RESTful (even if they didn’t really know it).

The makers of SOAP realized they needed to reinvent their brainchild.? Just as the pop star Prince turned himself into a symbol, the SOAP makers dropped the acronym and converted SOAP into a proper noun.? Despite ongoing rumors, this was not done to downplay the fact that SOAP is a protocol and not a software architecture style like REST, but rather to hide the fact that SOAP isn’t so “simple” after all (just trying reading all of the WS-* specifications if you’re not yet fully convinced).??

This desperation move was too little, too late, as famous web service providers like Google and Rackspace began deprecating their SOAP APIs in favor of RESTful ones faster than you could say “Yahoo!”

The busy developer’s guide to SOAP and REST

Although REST has gained popularity over time, SOAP still has a decent amount of legacy use.? The debate still rages on today between which one will reign champion.? Before you spend hours fretting over the choice between SOAP and REST, consider both were born to solve a problem that presented itself at the time and, unless you plan to create your own web service, the decision of which to use may already be made for you.

This wise author, having weathered the entire storm described in the above fairytale, learned the hard way that some technologies come and some technologies go.? Some buzzwords die and others get “re-synergized” by marketing.? To help simplify matters, he created a quick-and-dirty overview to help future developers better understand the differences between SOAP and REST:?

SOAP

  • “engineered” by greedy corporate thugs
  • is a protocol, not an architecture
  • bulky and verbose
  • can use a variety of transport protocols
  • uses too much XML
  • requires XML
  • favored by suits and security zealots

REST

  • “designed” by a benevolent open-source evangelist
  • is an architecture, not a protocol
  • lean and mean
  • married to HTTP
  • doesn’t use enough XML
  • can use JSON, CSV, and even RSS
  • favored by hipsters and script kiddies

Final words

As a developer, the choice between SOAP and REST depends heavily on prior work, the task at hand, and what the “in” crowd is talking about at the water cooler.? If the above chart still doesn’t help you make a final decision, consider the following:?

If your current project works fine with SOAP, then use SOAP.

If your current project works fine with REST, then use REST.

If you don’t know how to use SOAP, use REST.

If you don’t know how to use REST, use REST.

If you interviewed for your current job in a suit, use SOAP.

If you interviewed for your current job in board shorts and flip flops, use REST.

If your manager is older than you, use SOAP.

If your manager is younger than you, use REST.

If your colleagues wear Dockers and collared shirts, use SOAP.

If your colleagues rock gold prospector beards and waxed mustaches, use REST.

And if by now you still haven’t made your mind up, just use Berkeley Sockets and call it a day!

要查看或添加评论,请登录

社区洞察

其他会员也浏览了