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:
- 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
|
|
