REST vs SOAP was CQRS with WCF
Ben Kloosterman
It is not an intrinsic fault but it is how its often used in practice , in REST especially as a thin wrapper on a DB . With CQRS and de-normalized forms it’s a good fit for the read model which I use . You can even get REST directly ontop your SQL server … I have seen lots of poorly designed chatty SOAP systems as well and they performed abysmally but normalized data ( not trees or denormalized) seems common in most REST API’S I have seen ..
REST doesn’t have a nice way to handle commands urls like /Commands/CancelOrder ( or you have to custom dispatch which has pains ) and managing it is pretty yuck the even bigger issue you can’t use binary / reliable transports, fancy security and auto created strongly typed proxies which are huge win for most developers out there. I would hate to build an SOA across many services within a company with REST.
Im not saying SOAP is better than REST they both have their uses but I do object to Damien saying REST is great and SOAP and WCF are substandard.. and the original poster just wanted to send commands for which WCF is a good fit.
If a framework using post for returning http data its just a poor/ nonstandard implementation I would file a bug. I do agree there are very few good SOAP frameworks ( maybe only WCF but I haven’t used Axis a lot) .
Ben
From: ddd...@googlegroups.com [mailto:ddd...@googlegroups.com] On Behalf Of Greg Young
Sent: Monday, 17 June 2013 3:51 PM
To: ddd...@googlegroups.com
Subject: Re: [DDD/CQRS] CQRS with WCF
I'm a bit boggled by "rest causes lots of little calls" where as soap "has chunky calls" designing resources poorly might cause this but I don't believe it is intrinsic. I have actually seen lots of reasons to avoid things like soap (eg frameworks make a poor abstraction over http and you end up with as example everything making a post).
João Bragança
--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Ben Kloosterman
>Can you elaborate on what you mean by "REST doesn’t have a nice way to handle commands urls like /Commands/CancelOrder"?
There was a discussion on this forum before on how to organize commands , do you have public names or do you serialize them needing custom handlers which either need reflection or need to be changed every time a command is added.
I am not sure what the strongly typed proxies get you. If you are inside the enterprise you are probably using .net / java everywhere anyway. you can use Nuget to distribute your message types. What is the SOAP story like outside the enterprise? I can tell you it's pretty lousy for PHP (most popular web framework lol) or AS3.
PHP is not strongly typed so there is much less reason to use SOAP .
You don’t mean binary message types do you ? it’s a bit of a nightmare we have been there and done that with binary remoting / COrba ..Version management becomes unmanageable once you have several difference version type libraries in use, with each team having many client applications that used that which then communicated to different servers. This is why around 2000-2002 a lot of devs started using XML as the data despite the perf cost, it didn’t go pop when anything was wrong and was more robust with change. The next thing that happened was discovering services now all I do for someone to use a service is they check a single short document with all the services which just has a url for each or you send an email .. The person then just adds the proxy and in most cases he can work everything out for himself with intellisense and get up and running . This ease of use really helps spread the use of services and more shared code as the other teams do not want to get tightly bound to what you do and use your types.
If you mean share xsd or classes you can ( you can do it in source control don’t need Nuget) but there is more communication involved and they need a lot more skills to access the server , you need create a proxy etc .. In the above cases the developer needs zero knowledge of http , Soap , tcp how to build a proxy which means even a junior developer is productive. Now when you change your types on the server by adding a type things keep working , if the server changes or removes a name there will be an exception and they will simply refresh the proxy without communication and the compiler and intellisense show them what has changed. If there is a nasty breaking change you can change the version and they will get a SOAP exception. There are no documents to check , no emails , no Nuget or source code checks etc. The teams are independent. See why there is no reuse in OO.
However I do think it is safe to say that the REST style is not suitable for high throughput of commands.
Why ? I don’t think SOAP would have better throughput . If you’re talking small tcp binary packets than I would agree but I would be quite happy with SOAP on WCF up to say 10K- 20K commands / second over tcp ( higher for shared memory)
Ben
Suheel Hussain
João Bragança
--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Damian Hickey
Ben Kloosterman
Http over tcp is not a reliable protocol , http 1 was even connectionless.. Tcp is only reliable at the transport layer it does not guarantee service to service delivery eg that your PHP or C# app has received it and the response( and over phone networks even tcps guarantee is not worth much) ... Even further http stacks have very low timeouts. Some reliable connections can even handle a server being of for 5 minutes and its like nothing has happened ( except for delay )
Note this is useful for http because if you have a large amount of clients you don’t use a lot of resources and you can share them more equitably.
I rarely use reliable connections ( and even rarer persistent ) but they can be useful.
Ben
Ben Kloosterman
But it requires a very thorough understanding of the nuances and requires more calls ie more chatty ..
From: ddd...@googlegroups.com [mailto:ddd...@googlegroups.com] On Behalf Of João Bragança
Sent: Wednesday, 19 June 2013 5:09 AM
To: ddd...@googlegroups.com
Subject: Re: [DDD/CQRS] REST vs SOAP was CQRS with WCF
Ben Kloosterman
“
If you believe in simplicity, then don't use WCF. Seriously.
If you need SOAP over HTTP, use ServiceStack.
If you are going to do plain HTTP or, dare I say it, REST (which will be much more palatable to non C# / Windows devs), then use WebAPI, ServiceStack, NancyFX or Simple.Web. My personal preference is Nancy.
“
From: ddd...@googlegroups.com [mailto:ddd...@googlegroups.com] On Behalf Of Damian Hickey
Sent: Wednesday, 19 June 2013 6:51 AM
To: ddd...@googlegroups.com
Subject: [DDD/CQRS] Re: REST vs SOAP was CQRS with WCF
João Bragança
--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.