I will not pretend that I know a lot about any of these options however,
what I do like about SOAP is the ability to be handed data in a specific
type, e.g. string, int, datetime, etc. I suppose, although I don't know
for sure as there aren't very many WS providers that offer XMLRPC (at
least for the types of things I've looked into), that XMLRPC would
provide type support being that it is still XML.
I think that calling one easier than the other is kind of a relative
thing, I mean it really depends on what you need to do with the
information and which platform/language your consuming it with. I prefer
SOAP mostly because I develop for windows using .NET. I can reference a
SOAP WS and consume it just as easily as any DLL. To me, this is much
easier than trying to consume data from an implementation of phpGedView
[1]. In order for me to do that I would have to write a class that
passes arguments through one long string and returns the data (holding
session information as well). Then I would have to write another class
to parse out every possible combination of returned data, which gets
very tedious when there are complex relationships with the data (as is
usual with genealogy). I know this because about a half a year ago I got
about 50% done with a winforms interface to phpGedView [1] when my hard
drive crashed, I honestly did not want to do all that again.
I know what you mean about paypal though. I'm currently creating a
rather large data mining application for my company and am being pained
all the way by Paypal's API. It was simply not well thought out.
Creating several custom complex types just to return all data as a
string (with the exception of some datetime values) is just annoying.
Dave
[1] http://phpgedview.sourceforge.net/
Richard Pyne wrote:
On 13 Oct 2005 at 18:26, Mac Newbold wrote:
Today at 7:57pm, Dave Wagner said:
Let me push my luck and suggest that SOAP be presented as the
primary means of exposing the churches content. XMLRPC and REST
are just annoying IMHO (REST especially).
As long as we're presenting suggestions, I suggest allowing both
SOAP and REST/XMLRPC. I find SOAP annoying, because I think it is
too big and bloated and complicated. People (especially
developers) like "simple" as long as it meets their needs, and
only go complex when necessary.
Amen to the "simple", but I'm not sure I would call SOAP simple,
but I think it could be.
I recently finished a project for work interfacing with a
service (PayPal Website Payments Pro) that could have been done
in less than a day using name=value pairs, less than a week
using XML, but took 2 months using SOAP. I will admit that this
was my first project using SOAP and could have been much simpler
even using SOAP had the wsdl and xsd been trimmed down to only
what was needed instead of encompassing every minute piece of
data that the service provider has availble in every service it
offers (eBay). My experience has been that protocols and
standards that start with the word "Simple" seldom are.
--Richard
_______________________________________________
Ldsoss mailing list
[email protected]
http://lists.ldsoss.org/mailman/listinfo/ldsoss
_______________________________________________
Ldsoss mailing list
[email protected]
http://lists.ldsoss.org/mailman/listinfo/ldsoss
