Interface for a SOAP client

29 views
Skip to first unread message

RocketR

unread,
Feb 8, 2014, 7:14:17 PM2/8/14
to objects-...@googlegroups.com
I'm trying to write a Ruby wrapper for a SOAP service which supports a ton of attributes and multiple levels of nested objects. What would a good interface for such a library look like? I don't want to expose too much, like a raw xml builder, but also wouldn't like to limit the user by narrowing the interface.
Most of the api-client-gems out there are built for Rest, thus they usually don't have any nesting and you can just pass in a simple hash with the attributes. That design doesn't suit my case, so some better examples would be appreciated.

Thanks

陈睿杰

unread,
Feb 9, 2014, 3:13:50 AM2/9/14
to objects-...@googlegroups.com

http://savonrb.com


开启 2014年2月9日 at 上午8:14:18, RocketR (broil...@gmail.com) 写:
> --
> You received this message because you are subscribed to the Google
> Groups "Objects on Rails" group.
> To unsubscribe from this group and stop receiving emails from
> it, send an email to objects-on-rai...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

RocketR

unread,
Feb 9, 2014, 7:10:22 AM2/9/14
to objects-...@googlegroups.com
Yes, I know about Savon and I'm using it. The question is how to provide the data for the body of request.

Yevgeniy Viktorov

unread,
Feb 10, 2014, 8:33:05 AM2/10/14
to objects-...@googlegroups.com

When I faced the similar problem recently I considered to go with a simple wrapper and see how things going, here it is:
https://gist.github.com/yevgenko/8915506

I now have a model which responsibility is to provide interface to the SOAP service, i.e. only necessary methods.
So, the interface is designed just to success the domain model needs, but relies on the same client wrapper.

During development I applied few changed to the original wrapper to make it easiest to work with, for example replaced original response object with the body hash which
I found easiest to work with in context of application, and added some authentication helpers.

As the next step I'm going to see if anything also could be unified/simplified, moved to wrapper and then extract and release the wrapper as a client library in order to start getting some feedback ;)

p.s.
I just googled the topic and found the following article, perhaps might be helpful too:

Amiel Martin

unread,
Feb 11, 2014, 2:46:23 PM2/11/14
to objects-...@googlegroups.com
Here's what I'm doing, in case it helps.

I'm following the basic pattern described in Ruby Tapas episode 164: Mapper (https://rubytapas.dpdcart.com/subscriber/post?id=412).
It also uses the registry pattern (from Ruby Tapas episode 172: https://rubytapas.dpdcart.com/subscriber/post?id=431).


ItemGateway is the boundary for the Savon library; it handles making SOAP requests.
It is pretty small, but will the place for more requests in the future.
It knows little about the application domain, simply returning a hash of attributes as the come back from SOAP.

ItemVariantMapper handles translating attributes into the application domain. In my case, a product variant.
It knows about the application domain concepts, but knows nothing about the actual storage, and hands off only a simple struct.


I hope this helps,

-Amiel

--

RocketR

unread,
Feb 11, 2014, 3:33:01 PM2/11/14
to objects-...@googlegroups.com
Thank you for your responses. I wasn't quite precise in my question, SOAP is only a detail, I really don't need to reinvent a low-level SOAP client as there's already one that's good enough. What I would like to hear your opinion on is what's a nice way to pass a complex tree of objects to be used in a library(particularly, for SOAP request).

Thanks
Reply all
Reply to author
Forward
0 new messages