The key abstraction of information in REST is a resource. Any information that can be named can be a resource: a document or image, a temporal service (e.g. “today’s weather in Los Angeles”), a collection of other resources, a non-virtual object (e.g., a person), and so on. In other words, any concept that might be the target of an author’s hypertext reference must fit within the definition of a resource. A resource is a conceptual mapping to a set of entities, not the entity that corresponds to the mapping at any particular point in time.

Roy Fielding’s dissertation

Lean Services

Today's web service architecture use web endpoints to determine

  • the structure of object(s) and
  • function.
via method call approach. This is the same if it's SOAP or REST-like solutions.

Shopping List Parable

To tie web endpoints to object structure and functionality is not obvious, more a thing of IT history. It comes to communication pattern one would never accept in real live.

Given you have a good restaurant and someone to buy the things you need fresh from the market. Your employee would act that way:

  • drive to market...
    • buy 20 kg flour from marketeer1
    • driving to the restaurant
    • store it
  • drive to market...
    • buy 20kg tomatoes from fruit marketeer
    • drive back to the restaurant
    • store it
  • drive to market...
    • buy 5 kg mozarella, 2 kg parmesan from cheese marketeer
    • drive back to the restaurant
    • store it
  • ...

Since the car could be broken or the shop is closed or an accident happens or traffic jam one build some kind of observation system to inform you about these events.

If you're employee is a follower of the RESTful way, there are situations, when he has process these steps foreach tomato.

If you ask your employee how one can improve this task, he would offer you a compound services. But he needs five day to learn the new route.

  • drive to market...
    • buy 12 kg flour from marketeer1, buy 30kg tomatoes from fruit marketeer, buy 3 kg mozarella, 6 kg parmesan from cheese marketeer
    • drive back to the restaurant
    • store it
  • ...

That looks better but it's tied to a certain combination.

And if you need a new chair or flowers or decoration your employee need ten days to learn.

As the owner of the restaurant you would fire your employee. But since every candidate works in the same way, there is no alternative. They claim it's the state of the art with no alternative. And they sacrify the word API for this.

And they claim they need at least a new car start working for you.

Communication Concept

To come to a conclusion. ElasticObjects implements something where object structure and functionality is bound to a field in a compound object. Passive Object and Functionality are implemented as simple beans or pojos in the java world.

In a method oriented solution you are tied to a method with properly defined input parameters and return parameter. So the web-API copy this method structure to request/response pattern. When you are programming such an API is very helpfully to avoid errors at compile time. For a computer service and communication it's roundabout.

With the generic compound object and one web interface the client decides what he want to do and how in the message itself. And no hassle about arbitrary uri naming.

I think to rather straightforward and obvious. And it offers a huge transparent flexiblity.

To create some pseudo request for the shopping list:

This call isn't implemented yet, but it will easy to make the request work, since it a simple Java bean with an execute method which can be used in any context.

With this approach the combination of what to be done is free. The JSON send is a compound object filled by the calls in a way, the client decide. There is no need to implement something for each combination. And one can test it without web server, since the web server just send and receive messages. Nothing else.

If you need new product from a new shop it's just a new call. So thats the basic idea.

As with every parable the comparision lags. The products mean all possible methods a server would like to offer. This could be the GreetingCall or the computation of a ≡SinusValueCall or a database request.


One could embed arbitrary calls in a text context with templates calls. This give more flexibility than the batch type execution with JSON. If the content is not relevant, this is a process engine.

These templates are a call itself, so you are free to combine data operation and rendering even in the content.


EO interprets two simple straightforward extensions of JSON to trigger bean calls.

  • object mapping before field name with brackets
  • fields with _ will not mapped to the parent

The basic implementation includes template execution and is open source. It's really small, so it could used just beside existing solution.

EO does not implement something like the leanservices which comes from the SOA context.


This Page Elements
Get Method:
Post Method:
Page-Template: ≡ContentPage.html
Header: Header.html
Navigation: ≡docs_Nav.html
Content: LeanServices.html
Footer: Footer.html
Postversion of this page: