Building Facade Patterns on SOA Services

[Rajkumar Ramakrishnan]

We worked couple of years service enabling different reusable function within the enterprise, these services are all SOAP and they have a complicated and a heavy data model, am looking at some best practices of exposing SOA services as a API.

Are there any patterns already available in terms of exposing SOA SOAP services as an API.

[Jørn Wildt]

Sorry, but I can't help being slightly curious - a SOAP service *is* an API, right? So what are you looking for? How to transform a service oriented API to a resource oriented API? Going from RPC to hypermedia? Or? What goal are you reaching for?

/Jørn

On Mon, Apr 14, 2014 at 7:19 AM, Rajkumar Ramakrishnan <raj...@gmail.com> wrote:

We worked couple of years service enabling different reusable function within the enterprise, these services are all SOAP and they have a complicated and a heavy data model, am looking at some best practices of exposing SOA services as a API.

Are there any patterns already available in terms of exposing SOA SOAP services as an API.

--
You received this message because you are subscribed to the Google Groups "API Craft" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+...@googlegroups.com.
Visit this group at http://groups.google.com/group/api-craft.
For more options, visit https://groups.google.com/d/optout.

[MattM]

+1 Jørn

If the SOAP service was not well-adopted, or had perceived design limitations, chances are waving a wand over it to make it into pseudo-REST will just uplift those issues into a new syntax.  This is a great opportunity to take the API user's perspective and craft a highly usable API that overcomes those issues. Bridging between your well-designed API and its ancestor at runtime will be the easy part.

m@