Re: More efficient web service choice
Re: More efficient web service choice
- Subject: Re: More efficient web service choice
- From: Greg Hulands <email@hidden>
- Date: Thu, 19 Jun 2008 09:36:15 -0700
In the past I have gone with a REST interface which every request
takes an XML document as the requests body. I then have xsd's that
validate the xml - this gives me that little bit of extra input
validation. I use JAXB to hydrate the XML and then pass it off to a
controller to convert it to EO's so we can use the business logic in
them.
About 6 years ago when I tried to get SOAP working in WO with a cocoa
client, I had nothing but nightmares. This has probably improved since
then, but because I like the above design pattern, haven't bothered to
try it out again.
g
On 19/06/2008, at 9:19 AM, Guido Neitzer wrote:
On 19.06.2008, at 01:21, David den Boer wrote:
Same with us. A properly architected API solves all of these
problems and then some. You have to architect it using only
standard java data types -- dont use EOF/NS or collections -- you
screw yourself when working with non-java clients.
That is a really good advice and seems to mostly work - it just
wasn't that nice, when you tried using DirectToWebServices.
What I like best about SOAP -- its dead simple to develop for when
you use WO, and rock-solid.
Not my experience but as I"m not really into WebServices - YMMV.
If you're developing rock-solid enterprise class API's to be used
by clients across a wide spectrum of tools/operating systems, I
think you can do no wrong using SOAP. If you like PHP or RoR, go
the other way :-)
Hmmm. That's a pretty tough statement. Again: SOAP is anything but
simple and there are MANY MANY things that can go wrong - especially
with WebObjects where a lot of the important stuff like the WSDL is
created for you and you don't have to understand the things when
doing the simple example - and then it blows up when you try
something real ... I'm pretty sure I still have 5 year old bugs open
related to that ... but again, I might be wrong, I stopped using
SOAP because it never worked out for me. It always worked in my WO
to WO cases but customers had often problems getting their .Net apps
connect and we solved ALL these problems with a REST interface.
But that might just be a matter of taste (and requirements of
course). I like to keep it simple and SOAP is not a simple protocol
anymore ...
cug
--
http://www.event-s.net
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden