As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
What are the pros and cons of using a rest service vs a wcf service?
I am wondering which type to use and I was interested to find some sort of comparision.
Rest is a way of doing communication over the internet. It is a very basic process of picking addresses to serve as method locations and returning HTML standard data (javascript, css, html of course).
WCF is a .net library used to have two programs talk to each other using SOAP. Which consists of two very familiar programs trading class info.
Seeing as Rest is a process, and WCF is a class library, a better question might be "Rest vs Soap".
The bottom line is, if you need two apps to talk, you might want to use WCF. Even if the apps are not both written in .net. However if you need information to be accessed by web tech(usualy javascript access is done this way) you'll want to use Rest.
Just a quick side note though, WCF does Rest well too, so you realy can't go wrong there.
You're asking a question about apples and oranges. REST is pattern used in creating web services. I'm not an expert on it, but you can find plenty of details on Wikipedia. WCF is a Microsoft technology for creating web services (primarily using SOAP, although it's so configurable that you can do REST on it as well - see ASP.Net WebAPI).
Pros for WCF:
Very configurable - If you can imagine it, WCF can probably do it.
Simple to use if you're sticking to the Microsoft stack. Visual Studio does 90% of the work for you.
Cons for WCF:
Very configurable - It can be a bit of a pain to get it do exactly what you want sometimes, especially if you're new to it.
There can be some problems communicating between different technology stacks. I've heard of Java services curling up and dying when pointed at a WCF service. As far as I've heard, this is a problem with the Java libraries, not WCF, but who knows for sure.
That's all that comes to mind right now, but hopefully that gives a you a decent impression on WCF.
If you are absolutely sure that HTTP is the protocol you want to use and you want to embrace it as an "Application" protocol, not just a "Transport" protocol then something like ASP.NET Web API.
If you building a service for your servers in your datacenter to talk to each other then seriously consider WCF.
Whether to do REST is a completely different question. Will this service last for many years? Will it have many different clients? Will some of those clients be out of your control? If you answered yes, then it may be worth investigating what benefits the REST constraints can bring.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I am currently developing an application which by design has a three-tier architecture. It is composed of an administration website, a WCF webservice and a database. Of course, the website doesn't directly connect to the database, so that all requests and responses must pass through the service. The "problem" is that there are several entities involved in this application, and for each one of them I must support the basic CRUD operations and many more, which makes the service have right now more than 30 methods in a single endpoint. Since I already had to increase the maximum message size, I begin to ask myself if having all those methods in a single service is not too much. What do you think? What alternatives do I have?
I can't really give you a good answer since it kind of depends on the requirements and complexity of your application. Typically a CRUDy service interface is an antipattern you should avoid. There shouldn't be a one-to-one mappings between your data layer and your service layer. If there is then the service layer is kind of not pulling it's own weight. SOA is a huge topic that I'm only starting to get my head around but my understanding is that SOA's are supposed to encapsulate the logic of many operations. Ie (Authentication, Authorization, Logging, Scaling, Transactions, etc.)
http://msdn.microsoft.com/en-us/library/ms954638.aspx
Have you heard of the Repository pattern? That's a software design pattern where a particular class/assembly encapsulates the logic required for getting data into and out of the database. It's lighter weight then using full blown services and might be all you need if what you want is a good way of decoupling your application from the database. A really neat feature of the Repository pattern is that you can make all the methods of the Repository an Interface and then make a MockImplementation to perform testing on your business/UI layers independently of your database.
http://msdn.microsoft.com/en-us/library/ff649690.aspx
There is no real concrete answer to this question. It is a tradeoff either way. Try to keep the Single Responsibility Principle in mind. A couple options are to:
Create an endpoint per data type, putting CRUD operations into each. That would mean maintaining more endpoint configuration through.
Separate your methods into multiple files, but leave them in one class, using partial classes.
If all you are doing is CRUD operations for each data type, then maybe use WCF Data Services / OData instead.
Implementing the repetitive CRUD functionality over the WCF service could be a pain but if the service is not exposed globally (so you don't have to pay a lot for the authentication/authorization) you can save a LOT of time by using one of the two: ADO.NET Data Services or WCF RIA Services.
Whether or not 30 methods on a single service is a bad design - this is not clear. It's like asking whether or not a class with 30 members is a bad design - some people will say that it definitely is, most will comment "it depends on what you are doing".
Nevertheless, using HTTP for CRUD brings some restrictions - one of which you mention. You will not be able to insert/update large batches unless you increase the message size. You can also have some serious issues with transaction handling unless you somehow involve the transactions over http in an explicit way.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
This question was inspired by Jon Skeet's question here where he asked about people pain points with LINQ so I hope this question isn't out of place ...
Version 4 of WCF tackled, probably, one of the areas where many people struggled with WCF - namely configuration. However, from this tagged set of questions and other forums there are obviously other areas that people struggle with.
I've made a bunch of blog posts and screencasts in the past trying to focus on common issues (such as duplex, sessions, etc). I'm planning another set but want to focus on things that are causing people problems even with the changes in version 4.0.
Areas I see are things like
Instancing and Threading
Security
REST support
WCF and Silverlight
Large message processing / streaming
Configuration (still)
Serialization
And I'm sure there are more, so I'd like to get input and maybe we can make sure that the product team also get some feedback to the greatest pain points people have with WCF
I sometimes participate both here and on MSDN and after answering many questions my opinion is that the greatest pains people have are:
Configuration
Configuration is a pain even more then before. Simplified configuration makes a lot of things even worse because before this simplification if you made mistake in the configuration you got an exception. Today you will make typo in your service name (or you will forgot to add namespace) and your service will silently use another configuration.
Security
Security is a paint, it was a pain and it will be a pain.
Security itself is complicated and WCF is making this more blured because where programmers on other platforms use shared vocabulary based on real WS standards, WCF uses its own names.
Only subset of security standards implemented - one failure is missing UserName token profile with digested password directly in WCF.
When hosting services in IIS security features in services are completely shared with IIS and restricts settings for the whole site / virtual directory.
When hosting services in IIS basic authentication is handled in IIS - you must build custom module to handle it differently (but if you use self hosting you can use custom user name password validator in WCF directly - IIS should support that as well).
Bad support for generating security configuration when creating proxy from WSDL. Currently the best what WCF has is custom binding. Custom binding on client side is useful only when service is also WCF and uses custom binding. We need better support in security binding element to provide same configuration features as its counterpart in code. Then the WSDL importer should be able to use new binding element and create proxies for secured services. Once such importer is not able to import WSDL we will be sure that default WCF doesn't support security requirements expected by the service.
REST
Still a lot of people don't see difference between REST and SOAP and the most common mistake is adding service reference to REST service. Also problem of the REST is that it was added to unified protocol independent API but REST is heavy protocol dependent and is not message oriented. This will be hopefully improved in Web-API.
Protocols
It looks like new protocols or protocols versions are not added to WCF.
Extensibility
WCF has great extensibility unless you are trying to extend existing feature. If you decide to extend existing implementation you usually can't. For example to add mentioned UserName token profile with digested password you must do it completely from the scratch. You cannot extend existing user name implementation.
Edit: Last two are my personal pains.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Could you tell me the open source alternatives to WCF??
I'm a newbie and just started using WCF. I wanted to know about the alternatives that are open source too.
Also, what makes them better options/not so good compared to WCF.
Thanks,
Thothathri
There are open source projects for REST services - for example Open Rasta Perhaps you will also find some open source projects for basic SOAP services but I doubt that there is an open source project implementing all WS-* related stuff implemented in WCF. WS-* protocols are mostly implemented only in API from big companies - MS, IBM, Oracle, SAP, etc. Reasons are:
Complexity - implementing WS-* protocols means diving deep into tons of specifications. You must also implement them very carefully to be really interoperable and to do not reduce performance too much.
Support - WS-* protocols are usually used in B2B solutions where enterprises demands some guarantees and support.
Costs - developing such API takes really long time.
Even WCF implements only subset of WS-* protocols. But WCF is highly extensible so anybody can try to implement some of these missing protocols himself.
WCF doesn't states only for REST and SOAP services. It is also replacement of .NET Remoting and Enterprise services from older .NET versions. You will not find a .NET API which will also offer all this functionality.
I also highly recommend checking out ServiceStack, it's a config-free web service framework I started that lets you easily and rapidly develop web services with very little friction.
It provides an expressive friction-less environment as you're able to develop web services by using you're own POCO C# DTO's which also encourages best-practices web service development since you're easily able to create more batch-full, coarse-grained APIs.
It's aims to be more productive by closely fusing C# with HTTP where all C# objects returned get automatically serialized to the requested format with (XML, JSON, JSV, CSV, SOAP 1.1/1.2, HTML) supported out-of-the-box. C# Exceptions also get automatically serialized for you making the tedious things effortless.
One of the major benefits is not needing to be concerned with external formats and endpoints (which are taken care by the framework) and you're left with developing your logic in a clean-room, auto-wired and highly testable, DDD-like IService class.
You could use RestCake if you're trying to create RESTful services.
Mono project has an ongoing effort for WCF hosted in Github. As you know, System.ServiceModel is the main engine for WCF. You can find Mono implementations of these namespaces under /mono/mcs/class/System.ServiceModel.* . You can find project related updates and relevant contribution information here
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
Why is the Mono project implementing WCF interfaces and classes "as is"?
I do not understand what is the point to repeat Microsoft's design. My experience says that WCF is a huge framework with an implementation based on SOAP services. There are tremendous problems with their approach. It simply does not fit well for simple HTTP request processing cycle. Why not try to invent a better framework instead?
Update:
OK, I get it. :) I like the .NET platform, C# and I like that this platform is available on another OS, but ...
Don't you guys see that many things in the original (Microsoft) frameworks can be done better?
Look at System.ServiceModel.Channels.Message. This is one of big things of customization landscape.
Why do I see XML everywhere? How can I easily do anything with classes like this? It is feasible, but I cannot say this is good design for a general purpose communication framework. I thought that the purpose of the Mono project is not just bringing the .NET ecosystem to unix* but make it better.
I think the whole point is to make WCF platform available in other operating systems than Microsoft Windows. So, if you have an application developed with MS VisualStudio (Microsoft's compilers), you can deploy it on Linux or Mac OS X if you wish.
You can also use MonoDevelop and Mono Compilers if you decide to code WCF in alternative platforms.
Because not everything is suitable for a simple http request processing cycle. Because SOAP offers features REST does not. Because it hooks into a wide set of encryption, authentication and authorization options. Because what you see as as tremendous problems solve problems for others.
Mono exists to allow .net on other OS's. Mono is not about picking and choosing what to implement based on merit.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I am planning on putting up a web service, or some other service exposed over the internet. I would like to create an API for applications to interact with this service. I would like the API to be usable in different languages, such as Java, C++, C#, or PHP. How can I maintain one code base for my API, but distribute nice packaged binaries for all these languages? Also, I may want to consider this could be cross platform as well.
Update 1
I'm early days on Web Services, but I
think one of the key points is that
lots of tooling supports the
implementation of clients based on the
description of the service like WDSL.
I've not delivered any client-side
software with anything I've done, I
expect any user to be able to build
their own clients suited to their
needs. --Brabster's Answer
I am not opposed to making it a straight web service then giving out a WSDL file. But what if I want the client API to do some logic, encryption, error checking or so on?
Update 2
As far as expecting the client that is
using your API to do anything, you
can't! There is nothing you will be
able to do to ensure that the consumer
of the API will do anything right.
That's why robust error handling is so
important. You must check and double
check any and everything that comes
from the client. You must always be
suspicious of it, and even assume that
it is malicious. There really is no
good way around that fact. --Ryan Guill's Answer
My original idea was to create a DLL or Assembly in .NET, then the client is making calls into this code that is running client side. This code may talk via any communications protocol back to the server, but my API would be running on their box. I guess REST does not really accomplish this. It seems like in REST everything is still an HTTP post. It is almost web services with out soap.
Update 3
I have accepted Ryan Guill's answer. I think the general idea is that I need to expose a network service of some sort, with the lowest barrier to the client. That way anyone can connect. Then just have all my code run on the server. That seems to be accepted as the only want to really achieve the platform and language independence I am after.
Thanks for all the input.
I would use a REST API, similar to the way Flickr's API works: http://flickr.com/services/api/
It is fairly simple to create and maintain, the biggest downsides are that it takes a lot of documentation (but pretty much any way you do an API will have this issue) and that robust error handling is a must.
But in my opinion, it's the best way to create an API that is the closest to cross platform/cross language.
More information here: http://www.xfront.com/REST-Web-Services.html
Update: The submitter added the following to the post:
I am not opposed to making it a straight web service then giving out a WSDL file. But what if I want the client API to do some logic, encryption, error checking or so on?
I personally do not like using SOAP (using a WSDL). There is a lot of inherent overhead to using SOAP, both on the server and the client. I think that is why you see more and more public API's being written using REST. It really lowers the barrier to entry to the lowest common denominator, allowing anything that can use basic HTTP (GET and POST (also PUT and DELETE for the "proper" way of doing it)) to use the API.
Some more examples of public API's written using REST: twitter, vimeo, Google
As far as expecting the client that is using your API to do anything, you can't! There is nothing you will be able to do to ensure that the consumer of the API will do anything right. That's why robust error handling is so important. You must check and double check any and everything that comes from the client. You must always be suspicious of it, and even assume that it is malicious. There really is no good way around that fact.
Update 2: the submitter added the following to the post:
My original idea was to create a DLL or Assembly in .NET, then the client is making calls into this code that is running client side. This code may talk via any communications protocol back to the server, but my API would be running on their box. I guess REST does not really accomplish this. It seems like in REST everything is still an HTTP post. It is almost web services with out soap.
You can certainly do this, but that is only going to work for .NET languages, meaning that your cross-platform and cross-language benefits are out the window. And still, in the end, are you really preventing anything? The developer is going to either use your remote API, or your local DLL or Assembly. Either way, he is going to have to know how to use it and use it right, otherwise you are going to throw an error. All you are really doing is changing where the errors get thrown from. Which may be important to you (if so, mention why) but really isn't changing anything in the equation.
But you are somewhat correct in saying REST is kind of like web-services without the SOAP. Technically REST is web-services too, its just that web-services have come to generally mean SOAP. It really is a different way of achieving the same thing. The biggest differences are though that it takes more programming and thought on your side (and potentially more programming on the client side) but you trade that for robustness, less overhead in both the consumer and the server, and the widest possible audience for the API. It really is the lowest common denominator.
I'm early days on Web Services, but I think one of the key points is that lots of tooling supports the implementation of clients based on the description of the service like WDSL.
I've not delivered any client-side software with anything I've done, I expect any user to be able to build their own clients suited to their needs.
If you check out the flickr API as suggested by one of your other answers, I don't think they supply client side code, other people have built and contributed client side stuff.
I suggest writing the API in the Haxe programming language so that the source code can be directly translated to all the programming languages you mentioned. The Haxe programming language can be translated (or "trans-compiled") to all of the programming languages that you mentioned in the original post, as well as a few others.
Simple answer, no.
Complex answer: create an API and compile it to a COM dll. Then, just build the wrapper code for the languages that can't handle that.
Simple answer #2, make the original service so trivial, or so universally acceptable, as to not require an API (I usually implemented this through server-side database polling. Ugly but any language that can access a database can utilize the program).