1

Assuming we have a REST API (Implemented using springs RestController) that is accessed from remote as well as the same local machine (e.g. mobile phone client and some mvc component on the same server).

For local software components on the same machine i guess there are two extremes:

  • Either they perform actual HTTP requests on the local machine possibly introducing significant unnecessary overhead
  • Or they somehow call the implementation of the REST API directly through Java, possibly introducing too much knowledge about the API implementation to the dependent software component

Is there any recommended middle ground for spring-based applications? Some bypass that is optimized for local execution but does keep the API as a black-box?

Thanks

mibollma
  • 14,959
  • 6
  • 52
  • 69
  • Maybe RMI - read up here: http://stackoverflow.com/questions/2013793/web-services-vs-ejb-vs-rmi-advantages-and-disadvantages – 6ton Jan 07 '15 at 20:56
  • I guess you mean not offering a different API through RMI but making the REST API accessible locally through RMI right? – mibollma Jan 07 '15 at 21:26

1 Answers1

2

As a principle of good design, I always see the service protocol disjoint from the service implementation. In this way, you can expose the service (e.g. a simple Spring bean) as a REST service, an EJB or whatever needed. Yes, it is more code, but it makes the service more resilient and adaptable to the subleties of that specific techology.

With regards to your question, it really depends on what "on the same machine" means:

  • Same app, you may use the same bean as a dependency (if you move the service implementation out of the REST controller)
  • Same JVM, you may use an EventBus like Guava's and encode the beans using JSON or Protobuffer (recommended)
  • Same host, you may want to keep the services location agnostic and use plain REST/TCP as it is today. I do not believe that the overhead justifies added complexity, unless your performance requirements are trading-room like.

In short, if you do not have a very demanding performance target or you cannot certainly assume that these two services will always reside in the same host/jvm, REST/TCP is good.

Alessandro Santini
  • 1,943
  • 13
  • 17
  • Theoretically that sounds quite reasonable however in practice moving it out of the REST controller might be difficult as REST represents more than just the protocol. For this to really work we might need a higher level abstraction including uris, methods and the hypertext application language. – mibollma Jan 08 '15 at 21:37