We have a situation where we have an application that hosts 10-20 API’s for which we plan to implement contact testing . Will it be better to have a pact per Api against a consumer application or one pact for application which as acts as provider and each Api acts as separate interaction?
A pact (contract) is usually between two applications. If the provider application provides multiple endpoints or resources (what I think you're referring to as "APIs") then they are modelled as one or more interactions (test cases).
...or one pact for application which as acts as provider and each Api acts as separate interaction?
This is what you want, I think.
There are some popular CDC(Consumer Driven Contracts) testing solution, Spring provides Spring Cloud Contracts which is integrated tightly with Spring, Pact is another great solution for CDC .
In my micro-service examples, I provides examples using Pact and Spring Cloud Contracts.
The API consumer(which consumes APIs) and provider(which provides APIs) sides maintains a contract to ensure the API consistence.
Ideally the contract for each APIs should per consumer(if you are following B4F pattern, if not we can ignore the difference from consumers) and per version. Eg. user client v1.0, and v2.0 could be different.
Related
I have worked with both technologies yet I’m about to build a new backbone services layer and thinking about WCF vs Web-Api.
The idea is to create a layer of services that will be consumed by both internal .NET components and by front applications.
The following are issues are not relevant to this case:
TCP, UDP
Proxy generator
WS-* standards like Reliable Messaging, Transactions
I'm considering about 2 approaches:
Web-api for app front application above n-tier WCF services
Web-api for app front and for a flexible services layer, thus avoiding HTTP hop between services
Our system is financial oriented, some services will operate as data services using the using some kind of OData and some will perform complex financial transaction (using complex types).
I've read about the new stuff that was recently added to Web-Api 2 and it seems to be a leading platform. I've Googled a lot about pros and cons and that WCF is still alive (or frozen).
A few of the relevant references:
http://www.codeproject.com/Articles/341414/WCF-or-ASP-NET-Web-APIs-My-two-cents-on-the-subjec
http://msdn.microsoft.com/en-us/library/jj823172.aspx
Under the assumption that all the services are on the same LAN and this is targeted to enterprise system, what would you recommend and why?
Here's the question... Do you need transport layer flexibility or are you fine with them being http(s) only services? If the services are HTTP-only and (as you say) you don't care about proxy gen and WS-* then I can't for the life of me think of a reason why you'd use WCF.
The programming model for REST / plain old http(s) is just so much leaner, the MVC "style" much more natural and not to mention that WCF can just get really complex really fast, makes me think that I would need a really good reason to choose WCF in 2013...
Not to throw a spanner into the works, but have you considered Service Stack:
https://servicestack.net/download
That's what I'd be using... (btw I'm not affiliated with them in any way / shape / form).
If you need multiple endpoints/transport protocols, or the ability for other applications to consume your services in .NET and work with them as you would any other referenced library (via web reference and a SOAP endpoint) the WCF should be your choice.
If you're looking for something lightweight and convention-based and/or you're looking to create a RESTful API, and HTTP(S) is an adequate transport, then Web API is the way to go. In this case, if you want the strong typing that you'd get with a SOAP web reference you'd probably be wise to write a reusable library that acts as middleware for consuming the services and providing data.
Is it better to have lots of small deployments with a few web services per war, or to have one big deployment with lots of web services per war?
In this case, assume that all of the web services share a common backend and will benefit from code-sharing. For small wars shared code would have to be put into a jar project and included from all the smaller deployments. Now each war can be tested/deployed separately, but if the backend changes they all need to be updated rather than only one.
The backend in this case is yet another web service provided by a vendor. Updates to it are usually backwards compatible but not always.
I know there is no clear-cut answer but any experience shared will be helpful.
As a rule you'd want one war per service. The point is that a service does not have to be a single web-service (in fact some of the endpoint can be other technologies not just web-services). A service can expose multiple endpoints and contracts.
You'd group together related contracts e.g a service that handles user management can have APIs for both users and groups. However APIs related to Orders probably belong in a different service (and thus war).
If you slice the services pieces that are too small you can get what I call the nano-service antipattern where the overhead of a service is more than the utility you get from it
I'm about to start a project where we have a back-end service to do long-winded processing so that our ASP.NET website is free to do quicker requests. As a result I have been reading up on services such as WCF and Web API to get a feel for what they do. Since this back-end service will actually be made up of several services communicating to each other and will not be publicly available to our customers, it seems that WCF is the ideal technology for this kind of scenario.
But after doing a lot of research I am still confused as to the benefits and differences between WCF and Web API. In general it seems that:
If you want a public and/or a RESTful API then Web API is best
WCF can support far more transports than just HTTP so you can have far more control over them
Web API development seems easier than WCF due to the additional features/complexity of WCF
But perhaps my question boils down to the following:
Why would a REST service be more beneficial anyway? Would a full blown WCF service ever be a good idea for a public API? Or is there anything that a WCF service could provide that Web API cannot?
Conversely, if I have a number of internal services that need to communicate with each other and would be happy to just use HTTP as the transport, does Web API suddenly become a viable option?
I answered a couple of related questions:
What is the future of ASP.NET MVC framework after releasing the asp.net Web API
Should it be a WebAPI or asmx
As an additional resource, I would like to recommend you to read:
http://www.codeproject.com/Articles/341414/WCF-or-ASP-NET-Web-APIs-My-two-cents-on-the-subjec
If you want to learn more about REST, check this Martin Fowler article
Summaring up:
As far as I know, both technologies are being developed by the same team in Microsoft, WCF won't be discontinued, it will still be an option (for example, if you want to increase the performance of your services, you could expose them through TCP or Named Pipes). The future is clearly Web API
WCF is built to work with SOAP
Web API is built to work with HTTP
In order to take the correct choice:
If your intention is to create services that support special scenarios – one way messaging, message queues, duplex communication etc, then you’re better of picking WCF
If you want to create services 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 transports are unavailable, then you’re better off with WCF and using both SOAP-based bindings and the WebHttp binding.
If you want to create resource-oriented services over HTTP that can use the full features of HTTP – define cache control for browsers, versioning and concurrency using ETags, pass various content types such as images, documents, HTML pages etc., use URI templates to include Task URIs in your responses, then the new Web APIs are the best choice for you.
If you want to create a multi-target service that can be used as both resource-oriented service over HTTP and as RPC-style SOAP service over TCP – talk to me first, so I’ll give you some pointers.
One combersome bit of WCF is the need to generate new client proxys when input and/or output models change in the service. REST services don't require proxys, the client simply changes the query string sent or changes to parse and/or use the different output.
I found the default JSON serializers in .Net to be a bit slow, I implemented http://json.codeplex.com/ to do the inbound and output serialzation.
WCF services are not that complex, REST services can be equally challenging as you're working within the confines of HTTP.
ASP.net Web API is all about HTTP and REST based GET,POST,PUT,DELETE with well know ASP.net MVC style of programming and JSON returnable; web API is for all the light weight process and pure HTTP based components. For one to go ahead with WCF even for simple or simplest single web service it will bring all the extra baggage. For light weight simple service for ajax or dynamic calls always WebApi just solves the need. This neatly complements or helps in parallel to the ASP.net MVC.
Check out the podcast : Hanselminutes Podcast 264 - This is not your father's WCF - All about the WebAPI with Glenn Block by Scott Hanselman for more information.
On our services, we configure several endpoints, allowing us to publish the same interfaces to SOAP 1.1 and 1.2 clients and HTTP clients consuming either XML or JSON. Now that the WCF REST team has been merged into the ASP.NET team to create the Web API stuff, what will this mean for us in the future? Will it still be supported to expose WCF interfaces as XML/JSON services? Should we move the REST endpoints to the Web API framework? Will this be the last shift of the MS REST stack?
Good question. I don't work for Microsoft and I don't have any inside information but my understanding is that WCF will be able to expose XML and JSON forever. In fact if you are merely exposing JSON or XML endpoints you are not doing REST. The real question is do you use the HTTP verbs (DELETE, PUT, POST, GET) as part of your API or you are simply exposing methods that are equivalent to your SOAP methods. If you are using the HTTP verbs it may be a good long-term strategy to migrate the REST part to WebAPI. If you are not then you can happily use WCF (go ahead tell your cusomers you are using REST for marketing reasons, to marketing people it's just a buzzword anyway).
If you are using the HTTP verbs it is not that hard to have both WCF and WebAPI. All you need to do is remove all logic from the service itself and expose it as a business layer methods. Then both kids of services can use these methods, call them in the appropriate way and shape the results.
To answer this, you need to have a little history on the ASP.NET Web API.
Initially the ASP.NET Web API it was the WCF Web API, a project on Codeplex extending WCF to make it easier to support a REST-style service. WCF was entirely built on SOAP as its core messaging type, so using HTTP as anything other than a transport-layer protocol required a different approach, with a different set of attributes and generally didn't mesh well with the rest of the framework.
The WCF Web API was extending the WCF framework in all the ways required to support HTTP as an application-level transport mechanism. It was introducing request routing based on the resource URI, dynamic formatting according to the Accept headers and the other things which were previously missing from WCF.
However, it became clear during its development that these technologies already existed within .NET, in the MVC stack. Thus, the decision was made that rather than having two competing sets of technologies, they move the work over to the ASP.NET MVC team, and the ASP.NET Web API was born.
If you are doing a REST-style service, the ASP.NET Web API is much better suited to your needs than the WCF framework. The WCF team will not be progressing their support for the REST-style architecture; these features of the WCF framework are effectively subsumed by the Web API, where it finds a much more natural fit.
Should you re-write your services to use the new Web API? Well, the REST features of WCF aren't going to suddenly stop working. You should only consider the move if it gives you some features you're after (like dynamic content-format selection), or if you're looking to continually develop your API (as the Web API is significantly easier to use than WCF).
I have an existing set of singleton WCF services. They are long-running processes that do a lot of work on an ongoing basis and expose themselves with WCF service contracts for communication with other processes.
When the WCF Web API was being developed I was excited because it was looking like I'd finally be able to do away with all of the annoying contract stuff and simply provide a platform-agnostic REST API for each service and have the processes communicate via HTTP requests and JSON responses.
Now it looks like the Web API has become an IIS-hosted ASP.Net feature, leaving me trying to figure out if I'm just missing something or if my WCF services will no longer have the opportunity to provide a REST interface.
If the Web API is no longer really targeted at my scenario, what has the ASP.Net team envisioned with respect to non-terminating singleton processes that wish to provide an HTTP/JSON-based API to other consuming processes?
You do not have to host ASP.NET Web API services in IIS. There is an option called "Self Hosting" that will allow you to host your API services in another process (such as a Windows Service) if you would like. I imagine that your current architecture would work just fine as a self-hosted app.
You can self-host using ServiceHost as in this MSDN example. See related SO post. Essentially - IIS is not a requirement for WCF hosting.
If you are using webHttpBinding - you just need to create the WebServiceHost which extends from ServiceHost to support REST.