REST for local interfaces?

Question

I'm building a little user management tool which should be used with a web GUI (probably made with Wicket). Some of the services this tool provides should be REST-ful and now I wonder if REST should be the only external interface (having CouchDB with its REST interface in mind). The GUI part of the application would then make REST calls instead of local method calls. Both would be deployed to the same server.

Advantages of REST-only interface: loose coupling, unified interface.

Disadvantages: HTTP-Overhead, Objects need to be converted to and from transfer format (like JSON), harder to implement.

This disadvantages let me think, that I should use REST only for real remote interfaces. Have I missed something?

Answer 1

My Opinion (this is key) is that you should stick with REST only. why? because you said its a little user management tool. which means its a small and lightweight tool. why waste time building multiple interfaces unless it becomes clear that you need them?

that said, I'm not too clear on what you're trying to do. a GUI wrapper to what is essentially couchdb? or are there any other components? my original opinion probably sticks..

Answer 2

Any sort of remote communication comes with a cost. You should make sure you gain something that's worth it. Very often, the huge amount of infrastructure available to support RESTful HTTP - the browser, servers, intermediaries such as proxies and caches, tools such as curl or wget - as well as the fact that information within your backend becomes linkable, not to mention the well-though out standard methods, response codes, caching method etc. are worth it. Sometimes they're not – it's close to impossible to tell without more details of your application. And even then, whether or not all of the loose coupling benefits outweigh the cost remains a subjective design decision.

You might want to consider using a Web framework that doesn't force you to make such as decision, i.e. one that is RESTful for the human-facing part, in the first place.

Answer 3

Your original interface may well work well as a REST interface as well.

There are two big issues that you need to overcome.

1) Many GUIs have a workflow component built on top of the interface requirements. For example, a large form presented as several pages. These are primarily done for the Human users, as most Computers don't really care.

2) Modern browsers don't natively support all of the verbs of HTTP (PUT, DELETE, etc.).

The first one can be over come because the workflow can be simple presentation, with the goal being that they call the final REST call properly. Going back to the multi-page form example, on the last page of the form you can have all of the other pages embedded as, say, hidden fields. So, the final POST is simply all of the data necessary, just like a computer would do initially.

The second can be handled using a simple proxy. Specifically, if you want to do a, say, DELETE, you can pass the verb in to your proxy, which treats POST and verb=DELETE the same as a DELETE. Just ensure that your back end support both similarly. Or you can use Ajax on your pages to make the correct calls.

While the interface as presented via your GUI may not be "REST" at a pedantic, the underlying system IS, at least at a protocol level, because it all follows the primary constraints of the architecture.

Another thing you can do is accept URL Encoded forms as input, but return XML as output. The key here is that you can send along with the XML a XSLT stylesheet. Thus, when it's rendered in a browser, you get the full boat HTML with graphics, and buttons, and all the rest. If you call it via a generic client, you get pure XML with none of the "cruft".

You can meet halfway by using XHTML and microformats. The payloads won't be dramatically bigger than a pure XML payload, yet it's still normal, every day XHTML with CSS fun for rendering in browsers.