REST in REST-ful

The Web is made up of many resources and a resource can be any item of interest, for example, an online book store may define book as a resource and clients may access that resource with this URL : http://www.myEbookStore.com/Books.

As a result of accessing the above URL is that the representation of the resource is returned (e.g., books.html) which results in a state change of the client. Now the end users browser is displaying more than just the home page of the online book store, a more informative and detailed state than the previous.
Thus, the client application transfers state with each resource representation. Isn't this same as browsing a website over the INTERNET ???
WWW is like a REST system and many of such services are being used in our day to day activities like purchasing something from Amazon.com, using Facebook, and even using GMail. So you are using REST, and you didn't even know it.

REST stands for Representational State Transfer. REST is not a standard but an architecture. However REST does make use of certain standards like http, URL, XML , html etc.

Consider the case of myEbookStore.com which enables its customers to :
1. get list of books
2. get detailed information about a book
3. purchase books on-line

 

Get List of Books :
--------------------------
http://www.myEbooksStore.com/books

Note that "how" the web service generates the books list is completely transparent to the client. All that the client knows is, if he/she submits the above URL then a document containing the list of books is returned which is obviously displayed in the browser. Since the implementation is transparent to clients, myEbooksStore.com owner is free to modify the underlying implementation of this resource without impacting clients.So we can consider REST as a loosely coupled architecture.

Here's the document that the client receives:

    <?xml version="1.0"?>
    <p:Books xmlns="http://www.myEbooksStore.com" xmlns:link="http://www.w3.org/1999/xlink">
          <Book id="0120" xlink:href="http://www.myEbooksStore.com/books/0120"/>
          <Book id="0121" xlink:href="http://www.myEbooksStore.com/books/0121"/>
          <Book id="0122" xlink:href="http://www.myEbooksStore.com/books/0122"/>
          <Book id="0123" xlink:href="http://www.myEbooksStore.com/books/0123"/>
    </p:Book>

Note that the books list has links to get detailed information about each book. This is a key feature of REST. The client transfers from one state to the next by examining and choosing from among the alternative URLs in the response document. This is something like zooming the view on Google Maps. If you want to see the map of a location in Pune, the satellite will first zoom onto India, then Maharashtra and then Pune. At first level we get a list of countries from which we select India , then list of states in India from which Maharashtra is selected and then finally we get a list of districts in Maharashtra from which Pune is selected. We can see how data is refined gradually by taking decisions at each level. Lets get back to our BookStore example.

Get Detailed Information about a Book
------------------------------------------------------
The web service makes available a URL to each book resource.For example, here's how a client requests book 0122:

http://www.myEbooksStore.com/books/0122

Here's the document that the client receives:

    <?xml version="1.0"?>
    <p:Book xmlns="http://www.myEbooksStore.com"  xmlns:link="http://www.w3.org/1999/xlink">
          <Book-ID>0122</Book-ID>
          <Name>JSON explored</Name>
          <Description>This book explains JSON</Description>
          <Versions xlink:href="http://www.myEbooksStore.com/books/0122/versions"/>
          <UnitCost currency="USD">9.20</UnitCost>
          <Quantity>10</Quantity>
    </p:Book>

Again observe how this data is linked to still more detailed data - the versions for this book may be found by traversing the versions hyperlink. Each response document allows the client to drill down to get more detailed information. Thats the whole idea of REST, Representational State Transfer.

In-short lets summarize some important points related to REST/Web Services :

1. Client-Server model, where the client pulls representations.
2. Stateless, meaning state of the data provider is not important. So each request from client to server should contain all the information necessary to understand the request. For example searching google.com for the word "computer" is sent to google server as http://www.google.com/#hl=en&output=search&q=computer ... so the required information is sent from client to server irrespective of the state of the server... that's true because before searching, we never worry about the state of google's server.
3. Common interface. For example : All google search queries are accessed with a generic interface (e.g., HTTP GET, POST, PUT, DELETE) and there is no static page for all searches. Imagine having a static page like : http://www.google.com/computer.html for search results of "computer" keyword... a bad idea.
4. Interconnected representations - the representations of any resource are interconnected using URLs, thereby enabling a client to progress from one state to another.
5. Cache to improve network efficiency. Hence once a website is loaded all the external javascripts needed by the site will be cached.
6. Categorizing the resources according to the requirement of a particular resource. Clients can just receive a representation of the resource, or even modify the resource. For the former, make those resources accessible using an HTTP GET. For the later, make those resources accessible using HTTP POST, PUT, and/or DELETE.
7. Underlying implementation of REST needs to be independent of the URL or type of REST service (GET, PUT, POST, DELETE). This means a website can be built using either JSP or ASP, without impacting the service being provided to the client. Also data can be represented in JSON format or as XML format or any other structured format.

Note :  APIs built using REST or conforming to REST design/architecture are said to be RESTful.

WCF and ASP.NET Web API

WCF is Microsoft’s unified programming model for building service-oriented applications. It enables developers to build secure, reliable, transacted solutions that integrate across platforms and interoperate with existing investments. (ASP.NET Web APIis a framework that makes it easy to build HTTP services that reach a broad range of clients, including browsers and mobile devices. ASP.NET Web API is an ideal platform for building RESTful applications on the .NET Framework. This topic presents some guidance to help you decide which technology will best meet your needs.

Choosing which technology to use

The following table describes the major features of each technology.

WCF	ASP.NET Web API
Enables building services that support multiple transport protocols (HTTP, TCP, UDP, and custom transports) and allows switching between them.	HTTP only. First-class programming model for HTTP. More suitable for access from various browsers, mobile devices etc enabling wide reach.
Enables building services that support multiple encodings (Text, MTOM, and Binary) of the same message type and allows switching between them.	Enables building Web APIs that support wide variety of media types including XML, JSON etc.
Supports building services with WS-* standards like Reliable Messaging, Transactions, Message Security.	Uses basic protocol and formats such as HTTP, WebSockets, SSL, JQuery, JSON, and XML. There is no support for higher level protocols such as Reliable Messaging or Transactions.
Supports Request-Reply, One Way, and Duplex message exchange patterns.	HTTP is request/response but additional patterns can be supported through SignalRand WebSockets integration.
WCF SOAP services can be described in WSDL allowing automated tools to generate client proxies even for services with complex schemas.	There is a variety of ways to describe a Web API ranging from auto-generated HTML help page describing snippets to structured metadata for OData integrated APIs.
Ships with the .NET framework.	Ships with .NET framework but is open-source and is also available out-of-band as independent download.

Use WCF to create reliable, secure web services that accessible over a variety of transports. Use ASP.NET Web API to create HTTP-based services that are accessible from a wide variety of clients. Use ASP.NET Web API if you are creating and designing new REST-style services. Although WCF provides some support for writing REST-style services, the support for REST in ASP.NET Web API is more complete and all future REST feature improvements will be made in ASP.NET Web API. If you have an existing WCF service and you want to expose additional REST endpoints, use WCF and the WebHttpBinding.

http://msdn.microsoft.com/en-us/library/jj823172%28v=vs.110%29.aspx

Web Service

1. It is based on SOAP and return data in XML form.
2. It support only HTTP protocol.
3. It is not open source but can be consumed by any client that understands xml.
4. It can be hosted only on IIS.

WCF

1. It is also based on SOAP and return data in XML form.
2. It is the evolution of the web service(ASMX) and support various protocols like TCP, HTTP, HTTPS, Named Pipes, MSMQ.
3. The main issue with WCF is, its tedious and extensive configuration.
4. It is not open source but can be consumed by any client that understands xml.
5. It can be hosted with in the applicaion or on IIS or using window service.

WCF Rest

1. To use WCF as WCF Rest service you have to enable webHttpBindings.
2. It support HTTP GET and POST verbs by [WebGet] and [WebInvoke] attributes respectively.
3. To enable other HTTP verbs you have to do some configuration in IIS to accept request of that particular verb on .svc files
4. Passing data through parameters using a WebGet needs configuration. The UriTemplate must be specified
5. It support XML, JSON and ATOM data format.

Web API

1. This is the new framework for building HTTP services with easy and simple way.
2. Web API is open source an ideal platform for building REST-ful services over the .NET Framework.
3. Unlike WCF Rest service, it use the full featues of HTTP (like URIs, request/response headers, caching, versioning, various content formats)
4. It also supports the MVC features such as routing, controllers, action results, filter, model binders, IOC container or dependency injection, unit testing that makes it more simple and robust.
5. It can be hosted with in the application or on IIS.
6. It is light weight architecture and good for devices which have limited bandwidth like smart phones.
7. Responses are formatted by Web API’s MediaTypeFormatter into JSON, XML or whatever format you want to add as a MediaTypeFormatter.

To whom choose between WCF or WEB API

1. Choose WCF when you want to create a service that should support special scenarios such as one way messaging, message queues, duplex communication etc.
2. Choose WCF when you want to create a service that can use fast transport channels when available, such as TCP, Named Pipes, or maybe even UDP (in WCF 4.5), and you also want to support HTTP when all other transport channels are unavailable.
3. Choose Web API when you want to create a resource-oriented services over HTTP that can use the full features of HTTP (like URIs, request/response headers, caching, versioning, various content formats).
4. Choose Web API when you want to expose your service to a broad range of clients including browsers, mobiles, iphone and tablets.

delete duplicate record in SQL server

create table empp(id int identity ,name varchar(30))

insert into empp values('bhanu')

select * from empp

-- for selecting duplicate record

select name ,count(*)  cnt from empp e group by e.name having count(*) >1

-- for selecting non-duplicate record

select name ,count(*)  cnt from empp e group by e.name having count(*) =1

• 
  

--with having

delete from empp  where id  in (select max(id) from empp  group by name having count(*)>1)

--without having

delete from empp  where id not in (select max(id) from empp  group by name)

DELETE FROM emp WHERE ID NOT IN (SELECT MIN(ID) FROM emp GROUP BY FName)

delete from tableName where UniqueColumn NOT IN (select MIN(UniqueColumn) from tableName GROUP BY DuplicateRecoedColumn/DeletedDuplicateColumn)