- Visual Studio Project Templates
- REST Singleton Service produces a service that exposes the full HTTP interface (GET, POST, PUT, and DELETE) around a singleton resource, and it automatically provides both XML and JSON representations for the underlying resource.
- REST Collection Service similar to the REST Singleton Service only it also provides support for managing a collection of SampleItem resources.
- HTTP Plain XML Service provides ONLY the GET and POST operations for those who don’t care about fully conforming to the RESTful design and would rather build a REST/RPC hybrid service by overloading GET and POST using the HTTP Headers.
- Atom Feed Service template provides a sample implementation that shows how to programmatically generate and return a SyndicationFeed instance.
- Atom Publishing Protocol Service template produces a full-fledged AtomPub service capable of managing collections of resources as well as media entries.
- WebProtocolException allows you to directly set your HTTP status code.
- WebServiceHost2/WebServiceHost2Factory which provides a zero-config experience. Provide support for Help Page.
- Help Page and using [WebHelp] for annotation. Simply navigate to /help
- Added Extension methods to the WebOperationContext class.
You can download the WCF REST Starter Kit here.
For samples of using the starter kit, look at this A Developer Guide to the WCF REST Starter Kit.
- [WebGet], [WebInvoke] to define mappings for the Http Methods Interface
- UriTemplate to map objects to method signatures through WebGet/WebInvoke Attributes
- WebOperationContext to access the HTTP Request/Response including header and status code
- <%@ ServiceHost Factory=”WebServiceHostFactory” to auto-config the Web endpoints binding and behavior without edit web.config.
- aspNetCompatibilityEnabled(web.config) & AspNetCompatibilityRequirements(.cs) to access HttpContext
- (optional) using Microsoft URL Rewrite Module for IIS 7.0 to remove the .svc from the URIs.
- RequestFormat/ResponseFormat=WebMessageFormat.Xml/WebMessageFormat.Json through WebGet/WebInvoke Attributes.
- Use SyndicationFeed, SyndicationItem, SyndicationContent to build generic logical feeds.
- Use Atom10FeedFormatter, RSS20FeedFormatterClass to turn a SyndicationFeed object to Atom/RSS specific feed format. Method can use SyndicationFeedFormatter base class to return various formatter object.
- Use ServiceDocument, ServiceDocumentFormatter, AtomPub10ServiceDocumentFormatter, and Workspace to generate AtomPub service document. note: AtomPub as a standard application of the HTTP uniform interface(GET/PUT/POST/DELETE) but applied specifically to Atom feeds, which are modeled as collections of entries.
- Too tedious, try WCF REST Starter Kit. and you can download here.
Let us use a bookmark service as an example.
We can use PUT to create new user accounts because the client is the one picking the username that forms the new resource’s URI. If the client is successful, the service will return a 201 (“Created”) response. If the client attempts to use an existing username, the service will return a 401 (“Unauthorized”) response. When issuing the PUT request to create a user account, the client will provide a user account representation in the HTTP request body containing the user’s information.
For individual bookmark resources, we’ll support GET, POST, PUT, and DELETE requests. If a particular bookmark is marked as private, only the owner can retrieve it, but if it’s public, anyone can retrieve it. When a user creates a new bookmark, the service is responsible for assigning it a unique bookmark Id. Hence, the client won’t know the Id to use in the URI ahead of time. So, instead of using a PUT request, we’ll have users POST bookmarks to the user’s bookmark collection resource. The handler for the POST request will create the new bookmark, assign it an Id, and return a 201 (“Created”) to the client, specifying the URI of the new bookmark resource in the Location header.
This explains when to use POST or PUT for creating new resources. The answer ultimately lies in who is responsible for determining the new resource’s URI. If the client is in charge, the client can use PUT to the new URI (like we did for user accounts) and the service can return a response code of 201 (“Created”). However, if the service is in charge of generating the new URI, the client should POST the new resource to a factory URI like we’ve done for bookmarks. Then, the service can return a response code of 201 (“Created”) along with the URI of the new resource in the response “Location” header.
Once clients know the bookmark ID’s, they can issue PUT and DELETE requests to individual bookmark URIs to update and delete bookmarks.