Hi guys,
I'd like to take the conversation one step further and give you my opinion on "why I think we should go REST". Exchanging information online among apps is all about exchanging bits over a socket. The ways I've done this before are EJB, some sort of RPC implementation (i.e. spring rpc), WebServices (Axis) and simple custom HTTP calls. With the advent of "Web 2.0" completely different websites (apps) need to communicate with each other, besides screen scraping (for non-cooperative external apps), simple HTTP calls are great. Why should I have to implement a whole set of things just to get simple info from another app? As happens with EJB and WebServices (to a lesser extent), and that what happens with *ClientName* apps most of the time. Also, as we are using Javascript and JSON extensively we can leverage that knowledge to use JSON as a transport and not XML, which is waaaay better for these matters.
For the particular case Sofía mentions, a couple of cooperative servlets in each app would do for now. In the big picture, IHMO we should think in terms of exporting all the functionalities in, say *AppA*, as simple REST services that any other app can use with simple HTTP calls. We've already done this in a way with *AppB*, you can go an talk JSON to it through the Jabsorb bridge.
Well, this is a long email, we can discuss the topic further over the phone if you want.
Cheers,
Juan
La idea que quiero transmitir en realidad, más allá de si se implementa REST, RPC o whatever, es la de hacer una aplicación hackeable o hacker friendly. Cuando estás codeando esa fina capa de aplicación/servicios está bueno pensar en cómo vas a proveer esos servicios a todo el resto del mundo, que nadie piense siquiera en hacerte screen scraping, un buen ejemplo son los WebServices de Amazon. La sigo en otro post porque ahí viene el próximo entrevistado.
Posts
No comments:
Post a Comment