none
WCF Web API vs. WCF RRS feed

  • Question

  • So I have an upcoming meeting where I'm going to try and convince the development team to use the new WCF Web API vs. the traditional WCF as a new implementation of a middle layer. Some of the cons they will throw at me:

    it is an additional install current customers will have to apply as part of deployment as it is not part of the .NET Framework yet

    it is not a full-fledged release

    how do we support issues with non-release mode api

    The cons being stated, I still think the benefits outweigh the cons, Is there anyone with sufficient experience with the WCF Web API that can formulate decent rebuttal to these cons? Thanks.


    Enigmatic One
    Thursday, June 9, 2011 7:53 PM

Answers

  • As it turns out the question concerning whether to use WCF or the new WCF Web API depends on the context on how it will be used. If you are looking for a quick development time that doesn't require strict security (although security can be implemented) and ease of defining the data output (JSON, XML, etc.) then the WCF Web API is the route that makes the most sense. A hybrid solution could be created where the API exists in the same middle layer as the WCF. thx
    Enigmatic One
    Thursday, July 14, 2011 4:49 PM

All replies

  • I don't have a direct answer to your question (I don't have much experience with the Web API). However, as far as architecture is concerned, I think you're going about the decision all wrong. You should not be picking a solution and then looking for ways to defend it. Instead, consider the requirements of your project, and then pick out the solution that fits most naturally. Working backwards almost always leads to choosing the wrong solution for the job.

    1. What are the goals of your project? Do you control the clients, or are you publishing external services for third-party consumers?
    2. Like you mentioned, this isn't a full-fledged release yet, which means there is a risk of things going wrong. What are the implications to your project and clients if errors occur? Is it a critical system?
    3. Is this a short project, or long-term? More importantly, is the project flexible enough to be able to adapt to API updates if the web API is changed during the course of your project?
    4. You said that the pros outweigh the cons. Which pros in particular do you think are relevant? How do those line up with the goals of your project?

    If you can answer those questions well, and the Web API naturally fits in with what you're trying to accomplish, then you won't have any problem dealing with the cons you mentioned. If you don't have very good answers, or your answers point toward a traditional WCF service, then you are probably better off scrapping the Web API idea and going with the more natural solution.

    Friday, June 10, 2011 2:10 PM
  • Hi Tim,

    I believe the question was worded in such a way that caused the appearance of my approach to be wrong. The questions you asked are mostly already answered and the decision on technology to use based on those answers are very close in using either WCF or WCF Web API. Without getting too much into the details, here are some answers to the questions you posed:

    1. What are the goals of your project? Do you control the clients, or are you publishing external services for third-party consumers? Answer: Goals are to create a middle layer that it is more robust for internal developers to use and for customers to use. We do control the clients.
    2. Like you mentioned, this isn't a full-fledged release yet, which means there is a risk of things going wrong. What are the implications to your project and clients if errors occur? Is it a critical system? Answer: As a middle-layer it is crucial to make it work correctly, there is not much room for error. It needs to work effectively and is critical to the system.
    3. Is this a short project, or long-term? More importantly, is the project flexible enough to be able to adapt to API updates if the web API is changed during the course of your project?  Answer: The project will be long-term with the initial phase being short-term. This middle layer will continue to be enhanced for years as time progresses. 
    4. You said that the pros outweigh the cons. Which pros in particular do you think are relevant? How do those line up with the goals of your project? Answer: The WCF Web API is designed with a more 'REST-ful' nature using HTTP, which is more in line with the stateless nature of the web. It allows thinking about the services in terms of resources, rather than operations. This simplifies the implementation and is more fluid with the way the internet actually works. That makes the WCF Web API the more 'natural' solution. The WCF solution is more 'traditional'. Therein lies the problem.

    If you can answer those 


    Enigmatic One
    Friday, June 10, 2011 5:53 PM
  • As it turns out the question concerning whether to use WCF or the new WCF Web API depends on the context on how it will be used. If you are looking for a quick development time that doesn't require strict security (although security can be implemented) and ease of defining the data output (JSON, XML, etc.) then the WCF Web API is the route that makes the most sense. A hybrid solution could be created where the API exists in the same middle layer as the WCF. thx
    Enigmatic One
    Thursday, July 14, 2011 4:49 PM