News for hackers. Stuff that matters.
Re:REST in peace, SOAP by tptacek on Friday October 15, 2010 @01:19PM (#1795345)
The thing about REST is that executing on it involves understanding REST. The thing about SOAP is that you can practically push a button in your IDE and get a SOAP interface. No, the enterprise world is not about to transition to REST.
Re:REST in peace, SOAP by rubinelli on Friday October 15, 2010 @02:01PM (#1795527)
It's one button away... as long as you have the same technology on both sides (and then, why are you incurring all this overhead anyway?) Maybe this has changed in the last 3 or 4 years, but the last time I tried to get .Net and Java stacks talking via SOAP was a royal pain.
Re:REST in peace, SOAP by Roboprog on Saturday October 16, 2010 @03:03AM (#1797523)
Boy, you said it. I tried to upvote, but I guess commenting kills my upvote.

Fing "Enterprise". Beam me up Scotty, there's no intelligent life here.

IBM and Microsoft drop the SOAP, and we get stuck picking it up. I hate* implementing SOAP clients for random SOAP server implementation of the day..

I'm sorry, Rob will be back shortly. We apologize for the outburst :-) ...

Boy, you NAILED it exactly, though.

REST sure seems simpler: define the document/content types, or schema, and just use links to GET things. Save POST for the few things that actually change state, then document carefully how the content is to be sent back up.

It turns out a good deal of services really are READ-ONLY anyway.

Making the simple things simple: give me my damn document! Let's keep it encrypted, and I'll prove I'm authorized to see it:

https:/acme.com/service?acct=xxx&pass=yyy&item_key=123 ... Content: binary/what-you-wanted blah blah blah...

Painfully easy vs just freaking painful tweaking of SOAP nonsense. Die, SOAP, die!

Re:REST in peace, SOAP by RyanMcGreal on Friday October 15, 2010 @02:29PM (#1795628)
I'm experiencing this particular brand of hell right now.
Re:REST in peace, SOAP by derefr on Saturday October 16, 2010 @05:00AM (#1797638)
> It's one button away... as long as you have the same technology on both sides (and then, why are you incurring all this overhead anyway?)

If you want to make it look like you have an open API, while only having to do enough work to expose the way your two predefined systems already communicate, SOAP is the answer.

Re:REST in peace, SOAP by masklinn on Friday October 15, 2010 @02:36PM (#1795656)
We're talking about The Enterprise here, this kind of stuff is not even on the radar.
Re:REST in peace, SOAP by darklajid on Saturday October 16, 2010 @12:48PM (#1798264)
I'm part of a 7 figure project right now. We're a .Net shop, they have a Java infrastructure (and are as "enterprise" and process-laden as you can imagine and then some). We need to integrate -> See, we're right there.

SOAP it is for us and I do have to say that I'm rather relaxed. For us it's just one way (Java services, Java generated WSDL, we just consume/use the stuff), but it works rather well.

Unless you don't know about 3.5/WCF/Service References and try to do it the old-fashioned "Web Reference" ASP.Net way: That's a royal pain and just plain doesn't work at all for some (valid) SOAP things (some sequences of alternating complex types a la [Key, Value, Key, Value,...] for example cannot be mapped). Guess how I found out..

Re:REST in peace, SOAP by jmspring on Friday October 15, 2010 @01:36PM (#1795418)
While I agree SOAP will remain dominant in the enterprise space, so is Java. And there are Java frameworks out there like Restlet that make publishing RESTful APIs nearly as easy as SOAP for those in this environment.
Re:REST in peace, SOAP by kls on Friday October 15, 2010 @01:32PM (#1795399)
The thing about SOAP is that you can practically push a button in your IDE and get a SOAP

Sure, I am not supporting or detracting from SOAP, just highlighting the trending I am seeing in the SaaS space and I used Salesforce as an example because it is one that has made huge inroads into the enterprise space. It is the champion that got business executives looking at the advantages of SaaS. It is a logical conclusion that Accounting, HR, etc. will be adopted by the enterprise once someone mixes the formular right for SaaS in those spaces.