May 7, 2013 - 16 went

Book Club: Implementing Domain-Driven Design Ch 4 - 5

In this photo:

There are no tags for this photo

Added by Sean B.
on May 8, 2013.
 
1 of 1 pages

Comments

  • Sean B.

    Thanks for the book recommendation, Anshu. I think this picture gives a good summary of the differences. REST seems very similar to an ASP.NET MVC controller. I think it probably makes sense to use REST where you need to do AJAX from a UI or need access from a mobile device (both places you can't create proxy.) However, if you need access from C# code, there are advantages to WCF (SOAP). You can use protocols faster that HTTP (like TCP). At first glance (I still have much reading to do), it seems like security, reliable messaging and queuing would be better supported by WCF. I think it's very likely that we'll need both.

    or cancel

  • Sean B.

    BTW... The diagram is from: Scribner, Kenn; Seely, Scott (2009-04-17). Effective REST Services via .NET: For .NET Framework 3.5 (Microsoft Windows Development Series)

    or cancel

  • Sean B.

    Sue Hackett found this C# sample code for a DDD application. Seems to be the cargo example Eric Evans used in his book. I'm finding this very valuable. I could see reviewing this code as a topic for one meeting...or maybe a supplement for each topic. http://code.google.com/p/ndddsample/

    or cancel

  • Anshuman S.

    Thanks Sean and convey my thanks to Sue also. I have started looking into the code example and am definitely finding it very useful. Interesting thoughts on REST vs. SOAP, the more I talk to you the more I find myself convinced that there is "no single key to every lock". Pluralsight.com has some great courses on REST and SOAP. Let me know if you are interested, I can arrange for the video training.

    or cancel

  • Jason M.

    I disagree with that diagram in several ways, some factual and some based on opinion. You can't really compare REST and SOAP, you can only ask if a particular implementation of SOAP is RESTful; it's like asking if a Camry (SOAP) is a sedan (REST), not all sedans are Camrys and not all Camrys are sedans. There's nothing stopping message-level encryption and reliable messaging from being implemented in a REST style. REST is an architectural style, not a protocol or toolkit. SOAP (really the WS-* stack, not SOAP) is a protocol with lots of toolkits, but doesn't prescribe a particular architectural style, though the convention has been RPC (Remote Procedure Call). It's more accurate to compare REST to RPC, but it's arguable that either is a subset of the other, depending on your viewpoint. (Read the OAuth 3 spec for an example.) This is a good presentation that explains some of the misconceptions of using REST in an enterprise: http://www.infoq.com/presentations/Using-REST-for-SOA This a good presentation about what REST is and what it isn't: http://www.phparch.com/wp-content/uploads/2012/03/Keith-REST-Best-Practices.pdf - http://www.youtube.com/watch?v=sWdv5yFxHvA REST is protocol agnostic, so long as the protocol allows you to implement the six constraints. HTTP has the capability to be used for REST, but as we've proven with SOAP and the WS-* stack, it doesn't require you to use it RESTfully. That is, REST is not HTTP and HTTP is not REST. REST is in how you use HTTP (or FTP, or SOAP, or any other application layer protocol). The only times I've found where REST is not the best choice is when you have to optimize for sync time or throughput over scalability (with an exception for needing a system to be complete and you don't have time to build non-existent RESTful tools). With current hardware and tool capabilities, that line is drawn at the seconds level, not minutes (Amazon's S3 makes its systems consistent globally in under 8 seconds over 90% of the time IIRC.) But even then, it's not really a choice between REST and RPC, but a choice between an architecture that relies on active polling versus one that is event-driven, both of which can be implemented using a RESTful protocol over whatever level of the network stack you want. Though you may have to start removing certain constraints to improve transmission speed, such as self-descriptive messages and statelessness at which points its no longer RESTful. There are shortcuts that can be taken on client and server when both are fully under your control as well that save on dev costs and processing time, but I liken any non-RESTful client-server communication these days to Assembly, C, and F#: they are the best solution for niche problems, but they're never my default tool.

    or cancel

Want to comment on this photo?

Sign in, if you're already a member of this group or Join ALT.NET Atlanta Pragmatic Programmers

Other photo albums

Move photo

Do you want to move this photo to “__ALBUM_NAME__”?

Are you sure you want to delete this photo?

Yes, I'm Sure

Are you sure you want to delete this comment?

Yes, I'm Sure

Our Sponsors

  • Pluralsight Training

    Free Pluralsight .NET training videos -- entire course library!

  • VersionOne

    Hosting space in downtown Atlanta and Alpharetta, and food and drinks!

  • O'Reilly

    Review copies of products, donated books, items, discounts

  • Apress

    Free review copies, 50% off discounts, Giveaways for raffles/events

  • Manning Publications Co.

    User group discounts, Review copies, free books, speakers

  • eConsultants Inc

    Food and Drinks.

People in this
Meetup are also in:

Sign up

Meetup members, Log in

By clicking "Sign up" or "Sign up using Facebook", you confirm that you accept our Terms of Service & Privacy Policy