REST and WCF SOAP Frameworks.
Hi,
I have a question. I have a existing WCF type framework that has like 8 difference .svc's and in each one of those .svc's there are like 40 different web services (methods) that are called. This is in ASP.NET and C#.
I am going to start implementing REST aspects as well with ASP.NET and C#.
Is it wise to maintain 2 separate frameworks? One for REST methods (could also be 10-20 different methods) and that over existing SOAP svc's? Or do I combine the REST calls/process into the existing WCF?
If the suggestion is 2 separate frameworks... does anybody have an example of how that would be done in REST?
Any information would be greatly appreciated.
Thanks!
I have a question. I have a existing WCF type framework that has like 8 difference .svc's and in each one of those .svc's there are like 40 different web services (methods) that are called. This is in ASP.NET and C#.
I am going to start implementing REST aspects as well with ASP.NET and C#.
Is it wise to maintain 2 separate frameworks? One for REST methods (could also be 10-20 different methods) and that over existing SOAP svc's? Or do I combine the REST calls/process into the existing WCF?
If the suggestion is 2 separate frameworks... does anybody have an example of how that would be done in REST?
Any information would be greatly appreciated.
Thanks!
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
kaufmed, thanks for the response and answer!
I am of the opinion of maintain 2 separate frameworks and gradually converting the SOAP, where applicable, to REST. There are some dependency aspects that rely off the SOAP. But some of the other will gradually be converted to REST. There are some values in SOAP and I don't see it in REST like faultexceptions. One of the common themes, I have seen is that REST it limited on the error trapping aspects. But you are correct in the debug/testing albeit, I'm not so sure about something that as already taken place like in PROD. SOAP is just as limited as REST would be albeit SOAP has better probabilities to trap, IMO. Please set me straight if I am incorrect on that.)
I am of the opinion of maintain 2 separate frameworks and gradually converting the SOAP, where applicable, to REST. There are some dependency aspects that rely off the SOAP. But some of the other will gradually be converted to REST. There are some values in SOAP and I don't see it in REST like faultexceptions. One of the common themes, I have seen is that REST it limited on the error trapping aspects. But you are correct in the debug/testing albeit, I'm not so sure about something that as already taken place like in PROD. SOAP is just as limited as REST would be albeit SOAP has better probabilities to trap, IMO. Please set me straight if I am incorrect on that.)
ASKER
1) A webapi done in like MVC and the 10-20 different methods would be in the controller.
2) The SOAP (.svc) framework to do like the 40 different methods it has.
Is that a viable approach?
I know REST is has its pro's and con's. But outside of response size....what would/could be the determining factor on which to call when they are both available?
Any info on this topic would be greatly appreciated.
Thanks