I have two dumb/rookie questions. My problem is, I have NO idea where to begin learning this stuff.
Traditionally, I am an ASP.NET developer. I am familiar with creating and consuming traditional web services (.asmx) in ASP.NET. Now, I want to create some REST based services that adhere to the HTTP verbs approach. I intend to use WCF services to accomplish this. In addition, I want to create my services like Twitter in a fashion where the caller can reference [serviceName].[xml|json]. Unfortunately, i do not know how to allow the caller to specific the format. It seems like I need to create two seperate services which seems odd. Am I way off? Can someone point me in the right direction?
Thank you!
Check this tutorial. It will show you how to create REST service in WCF. Part 4 of the tutorial will also show you how to create REST service which is able to return both JSON and XML response. Be aware that this is for .NET 4.0 which added a lot of features to REST API (including automatic response type).
Juval Lowy's 2nd edition on Programming WCF is available. This should be an excellent source; his first book was outstanding. Michele Leroux Bustamante is another excellent author on WCF, but her 2nd edition book isn't due for another few months, so go with Juval Lowy.
Essentially, WCF separates protocol (binding) from code, so you should be able to write the service once, and use multiple end points (address, binding, etc.) to provide different formats.
The Programming WCF book has a 3rd edition out now.
Related
What is the difference between WCF Services and Web Services in .netWhen should I use WCF and when to use Web Services.Is REST and WCF service the same? Thanks
Web Service is an abstract term encompassing a large variety of data providers for distributed systems. Perhaps you are referring to ASMX web services, which can still be found in the wild but aren't really widely used in new development these days.
WCF Service is Microsoft's implementation of SOAP. There are others implementations or you could roll your own (not recommended).
SOAP is a kind of stateful, session-based, message-based web service. It's good if your service is designed as a set of complex actions.
REST is a stateless, sessionless, resource-based web service. It's good if your service is designed to access data and perform simple CRUD operations on it. SOAP and REST are mutually exclusive. A service cannot be both. There are ways to manipulate vanilla WCF to make is RESTful but these techniques are becoming deprecated. If you want to implement a RESTful web service there are two main choices in the Microsoft world: WCF Data Services and ASP.NET Web API.
REST is an architecture
WCF is a API in .NET Framework to build connected service oriented application.
In olden days a functionality developed as Web Service was accessible via internet and the same to be available on local network was available via Remoting.
Using WCF we don't need to develop different code for it to be accessible over internet and on local network. Just configuring it with bindings would be enough.
That is a very wide question...I am going to just give a brief high-level answer and suggest that you do some more searching as there are is already a lot written on each subject. But, hopefully this should give you a push in the right direction.
First, typically when people refer to WCF Services and Web Services, they are referring to the newer WCF conventions that make service calls fairly generic (they can be SOAP, REST, etc) and the old .asmx SOAP method of Web Services. So, along these lines, I would suggest looking more into WCF and SOAP/.ASMX for the difference of WCF and older Web Services.
As to WCF and REST, they are not the same. REST is more of an architecture, whereas WCF is a framework. As I already mentioned, WCF can be used to make SOAP calls or REST calls. I am not sure I can add much more without going into greater detail.
I will see if I can find some good articles on REST and WCF a little later, though. Personally, I do not see a reason to even pursue very far into the older way of calling web services (.ASMX pages) as WCF has pretty much made that obsolete. However, learning many different ways to skin a cat can be useful in an endeavor to find what fits you best.
Again, this is VERY high level, but these are very general topics with a lot surrounding each, so hopefully a high level overview will help direct you in studying deeper on each subject.
Some people mean "ASMX" when they say "Web Services".
Others just use "Web Services" to mean the generic technology, and consider WCF to be the current way to create Web Services on the .NET platform. The other kind are "ASMX Web Services", as distinguished from "WCF Web Services".
The "other kind" are a legacy technology, supported only for backwards compatibility. They should not be used for new development, so there's no point in you learning about them.
As others have stated, "REST" is an architecture style, not a technology.
WCF is multifaceted, so I'm going to speak of it with respect to its most common usage. The general difference between WCF and REST services is centered around the content. A REST call is usually more message/document/entity centered (With customer entities, find those starting with M; With order entities, get order 12 and is tied to the HTTP protocol. WCF tends to be more operation centered (Invoke find operation with params, Invoke get operation with parameters). WCF also isn't tied to HTTP.
FYI, there are extensions to create REST based services using WCF (WebInvoke, WebGet attributes).
Wcf:wcf is a technology as part of .net framework which provides environment to work with different distributed technologies an by following unified programming model.
wcf create a proxy.
wcf support data contract serializer.
records shown xml format.
**Rest:**Rest is an architectural style.which says use the existing features of the web in more effective,efficiency and simple manner.verbs like insert,update and delete.
Rest cannot create a proxy.
rest records shown jason format.
Web Service:a service which is hosted on website is called as webservice.
web service support xmlserializer
I see this is quite an old thread, but I have asked a similar question recently.
The answers given have all similar relevance, but in my opinion Ray was the closest to what was actually asked.
When designing or refactoring a web based solution, you always get the question should we go with SOAP or REST. The answer lies in the complexity of the business logic required behind the service. REST is good for simplistic API calls that usually contains small sets of requested data or over night processing with large sets, but mainly for data requests. SOAP is more of an interactive day to day service with business logic as well. For example many methods with plenty of parameters.
What we do as part of our web based solution, is to try and make use of both. For internal methods and primary functionalities we use SOAP, but for exposed APIs we prefer REST.
Framework related, definitely WCF as preferred choice, irrespective if SOAP or REST.
Is it possible to use oData with a WCF service application but not use WCF Data Services?
It will be great if someone could shed more light on oData. I have done some Googling on this topic, but whenever I search for "wcf odata", I get information about WCF Data Services.
Any help/links will be appreciated.
WCF Data Services is the Microsoft implementation of the general OData protocol. As such, only WCF Data Services are / support / implement OData - a "normal" WCF service does not (and can not).
You might need to elaborate exactly why you feel the need or urge to use OData but not use WCF Data Services. What's the issue / problem you have with that setup? WHY do you want to use only a "normal" WCF service??
Update: ok, so you want to have services that expose data in different fashions and with different methods. What you could do is create a regular WCF service that's exposing both SOAP endpoints as well as a webHttpBinding REST endpoint. This will work - but then it's a "regular" WCF service, with methods that take parameters and return some data structure. This is not WCF Data Service (OData).
OData is more of a "here's my data collection, you can browse around in it" kind of approach - it's more about exposing an entire data model to the outside world using REST. This doesn't mix and match with SOAP - which is a lot more procedure-oriented, e.g. LoadCustomer, SaveInvoice and so forth.
So while it's absolutely possible to have procedure-oriented WCF services exposing both SOAP and REST endpoints at the same time, I don't really see how you can mix and match the "expose-this-resource" kind of approach for WCF Data Services / OData with a SOAP binding - this just doesn't work, I believe.
So if you must expose your data model of WCF Data Services (OData), you will need to author a second, pretty different looking regular WCF services for the SOAP clients, that might be based on the same data in the end (access the same database, for instance), but it's "face" will look quite different.
There is a new(ish) project from Microsoft called WCF WebApi (NuGet Package), which is simplifying doing RESTful WCF. It really takes to heart the "Representation" part of REST, so that you can expose your data in many representations (JSON, XML, oData, PNG, etc) based on content negotiation (or optionally whatever convention you want) all from the same service contract operation. Currently baked into the framework is the ability to support oData GET queries, by simply returning a collection .AsQueryable().
While this isn't a pure WCF/oData solution, as your question is speaking to, I thought I would mention the project in case it fit your specific requirements. The current Go-Live licensing might prove prohibitive, as might the "preview" status of this code; but if not, this may be a solution for you.
* UPDATE * This project was rolled into ASP.NET (usually in conjunction with ASP.NET MVC) and is no longer under the WCF team. The new product is called ASP.NET WebAPI.
I'm pretty much a novice as far as WCF goes and I'm trying to figure out which type of WCF project to create for use by my windows phone 7 application.
There seems to be :
WCF Service
Silverlight-enabled WCF Service
WCF Data Service
As far as I can tell - #1 is an older variant, requires more configuration and an interface. #2 has some switches turned on that are required by Silverlight. #3 Talks to an entity model.
I am using an entity model so #3 looks good, but the examples I have seen look like it exposes the whole entity model. I want to pick and choose what tables to expose, plus create my own service methods using linq to join tables. Can #3 do this?
#2 looks better than #1 as it does not seem to require an interface and seems to have less configuration.
#1 looks most configurable which is both a good and bad thing. I guess this is my fallback position.
Any advice?
Cheers
Steve
What you're running into relates to the fundamentals of Silverlight (at least as it stands today.) Your conclusion is correct - the "Silverlight-enabled WCF Service" is probably your best bet for a quick service to call from the Phone app, but I'd like to offer a different take on the rationale.
Silverlight only supports a subset of the communication options offered by WCF - it only allows BasicHttpBinding, whereas WCF offers a whole lot more, including support for "enhancements" that are part of the WS-* specifications. As a result, you need to set certain flags and make certain choices in your WCF services in order to make them consumable by Silverlight. By using the "Silverlight Enabled WCF Service" template, that work is done for you. This also means that if you want secure web-service communication with Silverlight, you have to use/set up HTTPS.
As to the interfaces, etc., actually that works across both options - the need for setting up the ServiceContract vs "implying" it from the defined operations came around .Net 3.5 SP1, if my memory serves me correctly. Note that while "regular" Silverlight also has support for communicating with TCP-based WCF Services, I believe the phone does not.
Now for choice #3 - the WCF Data Service (or the artist formerly known as ADO.Net Data Services.) What this does for you is sets up a REST-based service to expose your backend data (where the previous 2 options are more/usually SOAP-based.) More details and introductory information on this can be found here - http://msdn.microsoft.com/en-us/data/bb931106.aspx. Now these services typically leverage plain old http, and are definitely consumable by Silverlight and the phone; also their payloads are lighter weight than the SOAP counterparts.
Whether or not to use REST or SOAP is a design choice - the SOAP approach is more RPC-like (define methods in the service that get called to perform specific actions with specific priorities), the REST option is more OOP-like, with some "auto-magic" thrown in for good measure. The thing about "auto-magic" is that you really do need to understand the magic (and its limitations) before you start, or your design could likely fail to meet your requirements.
Hope that helped!
John
When developing an application wich will be used inside an intranet do you think Silverlight and WCF is a good solution ?
Whould you use WCF Services or WCF Web Services to expose your model to the client ?
When consuming a WCF Service the proxies will be generated under a reference and you can only have 1 service reference per service, How can I have the application domain model created under the same service reference ?
Thanks.
A. Lampard.
Not yet. I had a difficult time getting WCF configured, and Silverlight 2 beta was not well documented.
Silverlight is out of Beta now, and compatibility with WPF has improved. If your skills are generally in .NET and you want a rich web application then Silverlight ought to be a no-brainer, especially on an intranet where you can reasonably guarantee everyone has Silverlight installed. Plus, it runs fine on Macs.
For services, WCF works with Silverlight and there are numerous examples of how they work together. Here's a video from the official site on that very subject:
http://silverlight.net/learn/learnvideo.aspx?video=47177
"Not sure if I understand your second question...not sure why would you want more than 1 reference per service...?"
When you have, for example, a ProductService wich uses the classes Product and Family, if you create the proxies for this service you'll get: ServiceReference1.Family and ServiceReference1.Product. Now supose you create the FamilyService, when consuming this service you'll get the Family proxy created again, but under ServiceReference2 !
Your questions is way too broad. It's really hard to answer these kinds of questions, since, really, "any" technology is good for "any" solution. Otherwise everybody would just use one!
What's your application supposed to do, how soon you need to get it done, is there any existing investment in the same or other technologies...etc.?
Having said that, to answer your question: yes.
Not sure if I understand your second question... not sure why would you want more than one reference per service...?
I am bit confused about ADO.Net Data Services.
Is it just meant for creating RESTful web services? I know WCF started in the SOAP world but now I hear it has good support for REST. Same goes for ADO.Net data services where you can make it work in an RPC model if you cannot look at everything from a resource oriented view.
At least from the demos I saw recently, it looks like ADO.Net Data Services is built on WCF stack on the server. Please correct me if I am wrong.
I am not intending to start a REST vs SOAP debate but I guess things are not that crystal clear anymore.
Any suggestions or guidelines on what to use where?
In my view ADO.Net data services is for creating restful services that are closely aligned with your domain model, that is the models themselves are published rather then say some form of DTO etc.
Using it for RPC style services seems like a bad fit, though unfortunately even some very basic features like being able to perform a filtered counts etc. aren't available which often means you'll end up using some RPC just to meet the requirements of your customers i.e. so you can display a paged grid etc.
WCF 3.5 pre-SP1 was a fairly weak RESTful platform, with SP1 things have improved in both Uri templates and with the availability of ATOMPub support, such that it's becoming more capable, but they don't really provide any elegant solution for supporting say JSON, XML, ATOM or even something more esoteric like payload like CSV simultaneously, short of having to make use of URL rewriting and different extension, method name munging etc. - rather then just selecting a serializer/deserializer based on the headers of the request.
With WCF it's still difficult to create services that work in a more a natural restful manor i.e. where resources include urls, and you can transition state by navigating through them - it's a little clunky - ADO.Net data services does this quite well with it's AtomPub support though.
My recommendation would be use web services where they're naturally are services and strong service boundaries being enforced, use ADO.Net Data services for rich web-style clients (websites, ajax, silverlight) where the composability of the url queries can save a lot of plumbing and your domain model is pretty basic... and roll your own REST layer (perhaps using an MVC framework as a starting point) if you need complete control over the information i.e. if you're publishing an API for other developers to consume on a social platform etc.
My 2ΓΈ worth!
Using WCF's rest binding is very valid when working with code that doesn't interact with a database at all. The HTTP verbs don't always have to go against a data provider.
Actually, there are options to filter and skip to get the page like feature among others.
See here: