Scribd
Upload
67 views

SOAP Vs REST

SOAP is a more rigid messaging standard than REST, relying on XML and various extensions for features like security and reliability. While SOAP is highly standardized and extensible, using it can be complex, especially when building requests manually in some languages. REST provides a lighter-weight alternative, using simple URLs and standard HTTP methods instead of XML messaging. The best approach depends on factors like the targeted web service and programming language. [/SUMMARY]

Uploaded by

Mohan Krishna
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
67 views

SOAP Vs REST

SOAP is a more rigid messaging standard than REST, relying on XML and various extensions for features like security and reliability. While SOAP is highly standardized and extensible, using it can be complex, especially when building requests manually in some languages. REST provides a lighter-weight alternative, using simple URLs and standard HTTP methods instead of XML messaging. The best approach depends on factors like the targeted web service and programming language. [/SUMMARY]

Uploaded by

Mohan Krishna
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 5

While SOAP and REST share similarities over the HTTP protocol, SOAP is

a more rigid set of messaging patterns than REST. The rules in SOAP are

important because we can’t achieve any level of standardization

without them. REST as an architecture style does not require processing

and is naturally more flexible. Both SOAP and REST rely on well-

established rules that everyone has agreed to abide by in the interest

of exchanging information.

A Quick Overview of SOAP

SOAP relies exclusively on XML to provide messaging services.

Microsoft originally developed SOAP to take the place of older

technologies that don’t work well on the internet such as the

Distributed Component Object Model (DCOM) and Common Object

Request Broker Architecture (CORBA). These technologies fail because

they rely on binary messaging. The XML messaging that SOAP employs

works better over the internet.

After an initial release, Microsoft submitted SOAP to the Internet

Engineering Task Force (IETF) where it was standardized. SOAP is

designed to support expansion, so it has all sorts of other acronyms

and abbreviations associated with it, such as WS-Addressing, WS-Policy,

WS-Security, WS-Federation, WS-ReliableMessaging, WS-Coordination,

WS-AtomicTransaction, and WS-RemotePortlets. In fact, you can find a

whole laundry list of these standards on Web Services Standards.


The point is that SOAP is highly extensible, but you only use the pieces

you need for a particular task. For example, when using a public web

service that’s freely available to everyone, you really don’t have much

need for WS-Security.

Difficulty Depends on Programming Language

The XML used to make requests and receive responses in SOAP can

become extremely complex. In some programming languages, you

need to build those requests manually, which becomes problematic

because SOAP is intolerant of errors. However, other languages can use

shortcuts that SOAP provides. They can help you reduce the effort

required to create the request and to parse the response. In fact, when

working with .NET languages, you never even see the XML.

Part of the magic is the Web Services Description Language (WSDL).

This is another file that’s associated with SOAP. It provides a definition

of how the web service works, so that when you create a reference to it,

the IDE can completely automate the process. So, the difficulty of using

SOAP depends to a large degree on the language you use.

Built-In Error Handling

One of the most important SOAP features is built-in error handling. If

there’s a problem with your request, the response contains error

information that you can use to fix the problem. Given that you might
not own the Web service, this particular feature is extremely important;

otherwise you would be left guessing as to why things didn’t work. The

error reporting even provides standardized codes so that it’s possible

to automate some error handling tasks in your code.

An interesting SOAP feature is that you don’t necessarily have to use it

with the HTTP transport. There’s an actual specification for using SOAP

over Simple Mail Transfer Protocol (SMTP) and there isn’t any reason

you can’t use it over other transports. In fact, developers in some

languages, such as Python and PHP, are doing just that.

A Quick Overview of REST

REST provides a lighter-weight alternative. Many developers found

SOAP cumbersome and hard to use. For example, working with SOAP in

JavaScript means writing a ton of code to perform simple tasks because

you must create the required XML structure every time.

Instead of using XML to make a request, REST (usually) relies on a

simple URL. In some situations you must provide additional

information, but most web services using REST rely exclusively on using

the URL approach. REST can use four different HTTP 1.1 verbs (GET,

POST, PUT, and DELETE) to perform tasks.

Unlike SOAP, REST doesn’t have to use XML to provide the response.

You can find REST-based web services that output the data in

Command Separated Value (CSV), JavaScript Object Notation (JSON) and


Really Simple Syndication (RSS). The point is you can obtain the output

you need, in a form that’s easy to parse within the language you’re

using for your application.

Deciding Between SOAP and REST

Unless you plan to create your own web service, the decision of which

protocol to use may already be made for you. Extremely few web

services, such as Amazon, support both. The focus of your decision

often centers on which web service best meets your needs, rather than

which protocol to use.

Soap Advantages

SOAP provides the following advantages when compared to REST:

•    Language, platform, and transport independent (REST requires use

of HTTP)

•    Works well in distributed enterprise environments (REST assumes

direct point-to-point communication)

•    Standardized

•    Provides significant pre-build extensibility in the form of the WS*

standards

•    Built-in error handling

•    Automation when used with certain language products


REST Advantages

REST is easier to use for the most part and is more flexible. It has the

following advantages over SOAP:

•    No expensive tools require to interact with the web service

•    Smaller learning curve

•    Efficient (SOAP uses XML for all messages, REST can use smaller

message formats)

•    Fast (no extensive processing required)

•    Closer to other web technologies in design philosophy

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy