Saturday, January 05, 2013

SOA - SOAP – WCF camp vs. ROA - REST – HTTP - ASP.NET Web API camp: Which one to choose?


 
Connected Systems:
One of the biggest challenges / opportunities in the industry is the integration and reuse of the existing systems.  Connectivity (Connect people, organizations, and existing systems) through connected applications becomes the key factor in the software development.  Solution to this challenge lies on developing interoperable, loosely coupled, secure distributed application.  
Around a decade back, Web Services and other RPC style framework assists the developers to build distributed applications.  The Windows Communication Foundation (WCF) simplifies development of connected applications through a new service-oriented managed programming model.  WCF takes Web services to the next level by providing developers with a highly productive framework for building secure, reliable and interoperable applications that send messages between services and clients.  WCF is pretty much mature now with .NET 4.5.
At the same time, there is another camp/ community where started using REST (Representational State Transfer) which is another different, alternative architectural style for building resource oriented services. The REST architectural style was developed by W3C Technical Architecture Group in parallel with HTTP/1.1. The World Wide Web itself, based on HTTP, can be viewed as a REST-based architecture. . Unlike SOAP, Restful services simply relies on the HTTP application protocol verbs (GET – Fetch, PUT – Replace, POST – Insert and DELETE – Delete etc…). REST was initially described in the context of HTTP, but it is not restricted to HTTP protocol alone. RESTful architectures may be based on other Application Layer protocols, but in real time, it is only used with HTTP.
At this moment, REST approach is gaining upper hand because of its simplicity and reach. Restful services won’t require any proxies to consume and it be reached by a variety of device and client platforms. Microsoft have seen the increase in emergence of Restful services exposed over plain HTTP rather than through a more formal RPC style (like SOAP or WS*).  Microsoft already moved many of its implementations away from SOAP based technologies to REST. But WCF is not dead yet, it is still very well alive and in certain scenarios, it fit’s better than REST. 
 
 
SOAP vs. HTTP
Before going into WCF vs. Web API discussion, I would like to discuss more on some fundamentals. Any technology you mention which has its own merit and drawback. SOAP and HTTP protocols have different purpose and usage.
Simple Object Access Protocol, is a communication protocol specification for exchanging structured information over HTTP. It is based on XML and platform, Language independent. It build on top of HTTP as an abstraction layer. From the past decade, everyone agrees that HTTP is the correct intended way for communication between applications over traditional remote procedure calls (RPC) between objects like DCOM and COBRA. SOAP is designed be versatile enough to allow multiple or any transport protocols including HTTP, SMTP, TCP, UDP, Named pipes or even JMS. One thing, I learned in the last few years in program management is any system which performs more than couple of intended functionality will eventually fail.
SOAP actually was simple, but over time it tries to solve multiple enterprise demands like security, transaction, trust, discovery, federation etc. and slowly becomes complex and less interoperable. But if you want any of the WS-* specification feature, SOAP is the correct approach. For example: SOAP provides end-end message security compare to point to point communication. If the SOAP message is routed via multiple intermediaries before reaching the last receiver, the message itself is not protected once an intermediary reads it. Another example, say if you want a distributed transaction feature in your services, SOAP supports distributed transactions through the WS-Atomic Transaction (WS-AT) specification. Of course there are ways to achieve transaction in REST approach, but SOAP, WS-* make the implementation easy.  
On the other hand, Hypertext Transfer Protocol (HTTP) is an application, communication protocol which is more than a simple transport protocol. HTTP itself provides most of the features like authentication, caching, and content-type negotiation, so why an additional abstraction layer or different protocol – SOAP which is on top of HTTP anyway. In many scenarios, where you want to build services where the goal is reaching multiple devices, client platform, highly scalable, easy to consume, REST / HTTP services is the correct option. You can make REST / HTTP services secure, as similar to SOAP via HTTP authentication along with HTTPS.
The key advantage with RESTful services are simpler and better reach. Is Web Popular?! ;) Web - WWW, which is omnipresent everywhere now. Almost everyone knows about Web. HTTP/RESTful Services simply follows the tenets of the web which provides the same reach to people. I will give you a specific example - Just think of accessing a Service as below. You can access whatever the book detail of any author you want through HTTP GET itself! No Soap Messages, Proxy etc.
amazon.com/authors/{author}/{book}
Ex: amazon.com/authors/ArunGanesh/VS2010
 
amazon.com/authors/{author}?book={book}
Ex: amazon.com/authors/ArunGanesh?book=VS2010
HTTP provides the following nine methods or verbs that we can perform on an identified resource.
  • HEAD – Similar to a GET request without the response body. This is useful for retrieving meta-information written in response headers.
  • GET - Requests to just retrieve the specified resource.
  • POST – Client sends data (message body) to the server for an action.  
  • PUT - Uploads or updates the resource.  
  • DELETE deletes the specified resource.  
  • TRACE - allows the client to see what is being received at the other end of the request chain and use that data for testing or diagnostic information  
  • OPTIONS Returns the HTTP methods that the server supports for specified URL.  
  • PATCH Is used to apply partial modifications to a resource. 
1.       In Web, every resource being referred by a unique identifier, also known as a universal resource identifier (URI).
a.       URL+URN = URI. URI / Segment of a URI map to Application Logic. In the above example you can see that the segment of the URL itself being mapped to an application logic.
2.       Utilize HTTP Verbs - HTTP GET, POST, PUT, DELETE etc.
3.       Utilize HTTP Headers for representing what content type is required and services is returning. For instance, you can represent things like: languages, authentication, authorization, accepted encoding, char set, content type, length etc...
ASP.NET Web API:
ASP.NET Web API is a framework for building and consuming HTTP services. It’s latest Microsoft platform for building RESTful services. ASP.NET Web API takes the best features from WCF Web API and merges them with the best features from MVC!
 
 
It supports the following features:
  • Modern HTTP programming model
  • Easily define your URI space using the flexibility of ASP.NET Routing
  • Rich support for formats (JSON, XML, form URL encoded, OData, custom) and HTTP content negotiation
  • Request validation using data annotations
  • Automatically generate rich help page documentation for your web APIs
  • Content negotiation and custom formatters
  • Filters
  • Code-based configuration
  • Server-side query composition
  • IIS hosting or Self-host
  • Link generation
  • Testability
  • IoC integration
  • Tracing
  • VS template, scaffolding
 
Check out this article to get an idea around implementation is of ASP.NET Web API: http://www.asp.net/web-api/overview/getting-started-with-aspnet-web-api/tutorial-your-first-web-api. You would have noticed how much it is integrated and part of ASP.NET MVC. 
I see WCF/ SOAP and ASP.NET Web API/ HTTP as two separate service design options that you need to choose wisely based on your current scenario.

 
Scenario
WCF 4.5
ASP.NET Web API
Need to support specific scenarios like Message queues, duplex communication, end to end message security, distributed transactions, one way messaging etc….
X
 
Already you have existing working WCF services and would like to add HTTP support additionally.
X
 
One code base to support both SOAP and RESTful endpoints
X
 
Need to create a resource-oriented services over HTTP
 
X
Your project is a MVC application and want to expose some functionality over HTTP
 
X
Want to build only a HTTP / RESTful services
 
X
Duplex communication over HTTP
SQL backend and need to expose OData endpoints
WCF Data Services


 

No comments: