RESTfulness of SOA with Single Entry Point

Question

I have a service-oriented architecture with a single gateway for all client requests. I like this because the gateway is tidy, hides all "internal" services, and acts as a dispatcher and homemade load balancer.

Because of my design, however, the client only ever knows about "one" resource. And must send up messages that have requested operations and their parameters defined in JSON.

{
    "operation" : "Login",
    "parameters" :
    {
         "username" : "John",
         "password" : "1234"
    }
}

Should I be sad because my architecture is not RESTful? Am I not leveraging HTTP like REST prescribes? Please critique.

Answer 1

I don't know if "sad" is the right word, but one of the arguments in favor of REST, especially as implemented in using HTTP "properly" is that it provides to you, for free, the following (taken from Fielding's dissertation):

• Client-Server interaction, separating UI from data storage
• Stateless Server, improving reliability and scalability
• Client Cache, reducing some network traffic
• Uniform Interface, decoupling implementations from the services they provide
• Layered System, where each component is only concerned with those just below or just above it
• Representation Orientation, where you think in terms of resources
• HATEOAS, where your application essentially navigates links
• A constrained interface, with a small number of verbs (e.g. GET, PUT, POST, DELETE, and only about 3 others)

When you go with SOAP or another RPC solution, instead of REST, you are in theory giving up some but not all of these characteristics. You may be giving up client cacheability and you are thinking procedurally, and you probably can't use all the safety and idempotency conditions that RESTafarians exploit to a tee.

RESTful services have become very popular and not by accident. But does that mean you have to build RESTful services or that non-RESTful services are inherently much worse? I don't think so. I've done a couple RESTful SOAs for two different companies and while I prefer to SOAP (which seems bulky these days) and to home-grown APIs like yours (which, even if elegant, aren't standard), I don't diss other approaches and dismiss them as inferior.

If you are going to go with your own API, and return only 200s and 404s, and do everything with GET, then yes your API is conceptually simple and perhaps it will work fine for you. But if you need a variety of media types, and you have persistent storage requirements containing collections that are often appended to, deleted from, created and updated, then learning modern RESTful API design will at least open up new ways of thinking for you.

Bottom line is don't feel sad nor feel like you have to go to REST because everyone else is doing it. But the advantages are real and REST is not just hype.

Answer 2

Nope. Basically you have a home brewed SOAP style RPC using JSON instead of XML.

You might ask whether it's worth reinventing that with JSON rather than using a SOAP stack, but if you're talking to JavaScript, it might simply be easier to to use than SOAP, plus there's no burden of conforming with the SOAP standards/tool sets.

Other than that, seems fine to me.