RMI vs REST Service

Question

We are developing a service for our portal / web client developed using JSF . My advice was to expose the service as REST but another team member said to go with RMI implementation since its easier to deal in java object from development and testing point of view.

My argument was development and testing efforts with be pretty much the same but we will get all the goodness of REST web services.

FYI : We already have REST setup so there is no extra cost in framework support. This services are exposed for our smartphone client who uses REST api.

At the end our Manager decided to go with RMI way but I still think REST would be smarter way.

What would be your choice REST or RMI?

Note : Nothing against my team member or Manager just trying to learn here.

Erotic

There's not enough info for a definitive answer, but if you already have a REST API, you're manager should have a really good reason for adding another remoting choice to the mix. – Embowed

RMI is fine if you are running in house. anything client/server over the general internet should be using a modern webservice protocol. – Unexpected

Answer 1

If there are firewalls between your client and server, it is likely that RMI traffic might be blocked. HTTP traffic is open on most firewalls and REST should have no problem getting through.

Meteorite

This can be a big problem if you are selling your software into companies - they don't like opening up ports for RMI, but hey, they'll let you tunnel anything through HTTP(S)! – Embowed

You can do RMI over HTTP as well. – Danielldaniella

You can open firewall's port! – Crimpy

Answer 2

The biggest argument against RMI and for REST/SOAP etc is that the client does not have to be Java.

If your front-end could change down the road from JSF to ASP, then you'll be in some trouble.

Other than that, RMI is the way to go. An even better way to go is EJB ( which is a layer on top of RMI ) with additional advantages -- lots of vendors already implement the EJB spec, you get the advantages of object pooling, transaction management etc.

Corriveau

If you mean with EJB Enterprise Java Beans then I disagree, it would be a huge overhead to do anything EJB related if you only need RMI. – Atalya

fiinal static publicly eternally immutable boolean isEjbDead () { return true;} – Circumscribe

Answer 3

Is the client in Java, use RMI. But that is to simple thought. As it is only a point to point protocol.

REST as a paradigm is interesting if you have e.g. many reads and like to use HTTP technologies for caching etc. The next thing is you likely can easy implement "paging cursors" so you send data as a small page and add info how to retrieve the next page.

Your question basically is formulated as if it is a technology question. Which is the wrong approach. You should not bother about technology but about system architecture. The whole software system, its abilities, its performance, its scaling, its configuration and its maintenance is completely different depending on your usage of RMI or REST.

Beard