Create your first RESTful service with WCF 3.5

What is REST: 

read more about REST here  

REST is a term coined by Roy Fielding in his Ph.D. dissertation to describe an architecture style of networked systems. 

REST is an acronym standing for Representational State Transfer.

Problem with SOAP: In particular web scenarios, it is necessary to have high interoperability and to use only XML messages for transmitting over HTTP without the advantage of the high end WS* specification of the protocol. For security, we can still reply in HTTPS and SSL. So now it's becoming pretty common to use SOAP without WS* specifications when we need to achieve high interoperability. This is where REST is useful. In a nutshell.

Hence many used SOAP without WS* specification

Often called simple SOAP

Increases interoperability potential

Framework / tools hide XML / HTTP, i.e. tool support for generating clients and server from WDSL definitions which create XML schema automatically and that schema hides underlying XML details. So that way developers still go for SOAP because of tool support from all major vendors, even though that may not be able to take advantage of many additional protocols that were designed to support.

What is POX: When we do not really need SOAP?

It is just exchanging XML message over HTTP without SOAP, referred to as plain -Old XML (POX).

Using this, interoperability is virtually guaranteed.

But working with this involves direct coding for XML and HTTP, which is complex at times. Have to use various XML API for writing XML based codes, and has to be familiar with HTTP stack for actually programming logic for sending and receiving messages. This is one main reason why many developers switch back to SOAP programming model, which have tool support and automatic code generation especially at the client side. 

POX applications can be defined in a RESTful way when actions are defined by HTTPS verbs.

Understanding REST

REST is not a protocol like SOAP is; it is an architectural design.

An architecture for building services that build on HTTP.

Fundamentally different from SOAP

SOAP defines a transport neutral model focused on custom operations

REST defines transport specific (HTTP) model focused on resources.

Builds on a uniform interface and common data formats

HTTP methods: GET, POST, PUT, DELETE, etc.

In SOAP we define and rely on custom service contracts / operations.

In REST, we focus on defining resources and use unique URI to identify and represent these resources. Then we build services around these uniform interfaces instead of custom service contract that all services will use. So when we use HTTP to implement RESTful services, these uniform interfaces are defined by HTTP methods, i.e. GET, POST etc, so those operations that would be able to invoke on our resource. And when we get a resource then would be retrieving a representation of that resource over the protocol. So what we get is a representation of our resource and we can use a wide variety of formats to represent that resource. But in the end we will always use a uniform resource to interact with those resources that are exposed by a service.

 

Data Formats: HTML, XML, JSON, RSS

REST versus SOAP:

SOAP emphasizes Verbs while REST emphasizes nouns or resources.

Read more: C# Corner

Posted via email from Jasper-net