Share via

And while you are at it… why can’t I compose REST calls?

  • Article

In my last post I asked why you can’t compose SOA method calls efficiently.

With REST services like ADO.NET Data Services having nice uniform URLs too, and a model (aka EDM) why can’t I compose those with my SOA methods too:

i.e. expounding on my earlier example:

var manager = GetManager(GetDepartment(GetEmployee(“alexj”)));

What if I know a REST Url for an Employee:

i.e.

https://server/my.svc/Mailboxes(alexj@acme.com)/Employee

If I know the type returned from the URL is an employee, why can’t I compose it with a method that takes an employee something like this?

var manager = GetManager(GetDepartment(
“https://server/my.svc/Mailboxes(alexj@acme.com)/Employee”
));

This of course wouldn’t compile (Unless you had an implicit conversion from a string / url) to an Employee somewhere).

So you might want to inject a method to make it compile:

var manager = GetManager(GetDepartment(Load.FromUrl<Employee>(
“https://server/my.svc/Mailboxes(alexj@acme.com)/Employee”
)));

Either way the point is if the REST and SOAPY endpoints both share the same model, we could obviously extend the composition idea I introduced in my last post to allow composition across these two types of services.

But now you are starting to see some real power.

You can have a very limited set of SOAP Service Operations, and allow for almost infinite composability simply by opening up a couple of Astoria style REST endpoints. You can use those REST endpoints as parameters to your SOAPY service operations.

This combines the flexibility of REST with the tight contracts of SOAP without a lot of the latency.

Nifty…

So when will I be able to do this?