This makes sense for backwards compatibility reasons since it fits in with the existing REST API. An alternative if starting from scratch would be to design an event-based realtime API that uses WebSocket with long polling fallback.
To start: I'd like to have seamless R/R via stateless HTTP as well as websockets. I'd like to also implement transparent push events via SSEs and the aforementioned socket transport.
Naturally, inter-service communication would use the already-present MQ.
The workflow in this true "microservices a la carte" solution would look like:
Initial, one-time setup:
1) Set up NSQ (or other supported MQ - I'll start with NSQ)
2) Set up standard, client-facing frontend servers (stateless HTTP, sockets, SSE) bound to queue.
3) Set up DNS names for frontend load-balancers (ELB, heroku load balancing, whatever) for each frontend.
---
Writing a service:
1) In your language/framework/stack of choice, create a new project, include standard-sauce, language-specific server library.
2) Write a function to do what you want. (retrieve a list of users, create a post, whatever)
3) Register/bind the aforementioned function to a specific, standard, interfaceable name (using the service library)
4) Configure service library to connect to initially-setup message broker.
The end-goal is to have a standard RPC interface, standard pub/sub interface, standard message fabric across front-end clients (browser, mobile, whatever) and back-end clients (inter-service communication).
---
Internally, a call message might look like:
{method: "get", action: "users", requestId: "21739dfe-fbeb-4da9-b698-c5720cbc488d", timestamp: "2014-12-25xxxxxx"}
This will seamlessly map to:
HTTP GET (Frontend): http://api.mydomain.com/users
Websocket message (stateful) (Frontend): {method: "get", action: "user"}
ServiceLibrary call (Ruby): "Project.call(:get, :users)"
ServiceLibrary call (Node): "project.callFunc('get', 'users', callback)"
.. and you get the idea. No prescription necessary.
---
If you like ActiveRecord, Ruby, the Rails stack: rip out ActionController, rip out Rack, use the stuff you want.
If you want to use some of the amazing JS frontend rendering toolchains: hook em up.
If you need to write a simple, highly-concurrent microservice, try Go.
Rather than prescribe an entire solution (a la Meteor, Derby, etc.), take the best tool for the job and throw it at the situation.
---
The scaling story is cool, too: if your ActiveRecord-driven microservice is unable to keep up I/O throughput, rewrite it or just spin more instances up. Totally shared-nothing in this case.