0

My team is developing a multi-tier API with scalability and modularity in mind. The public access point of the API is fully REST. However, we are splitting the data access layer as another tier in our architecture and this layer will be on another physical server. We decided that RPC would be a good communication protocol between the public facing API and the private data access layer.

We decided to use RPC over REST for the private communication between our tiers because:

  • Avoid REST routes duplication between each tier
  • Transparency in executing code/functions on different servers
  • The communication is private. With good documentation there shouldn't be any problems for the team to understand the communication protocol.

My question are:

  • Did we miss advantages or disadvantages in the choice of communication protocol for the private communication between tiers?
  • What is normally use to communication between tiers in a multi-tier architecture, especially for web APIs?
|improve this question
  • It sounds like you're second-guessing your decision. – Robert Harvey Feb 11 '14 at 3:47
  • I am. The more I read online it seems there are really few good uses for RPC and that REST is superior in almost every aspect. I love REST and want the public API to be fully compliant with REST standards but it didn't seem like a good idea for the private communication between tiers. RPC seemed to fit but now I'm wondering if REST would have a been a good decision too. – Chris911 Feb 11 '14 at 3:58
  • One factor is whether or not the tiers cross an Internet boundary. If the tiers are intranet (and will stay that way), you can probably use anything you want. – Robert Harvey Feb 11 '14 at 4:36
  • All the tiers will be on AWS. The public API will a public IP address and domain while the data access tier will only be accessible from our AWS cloud and not for public access. At this point I know we can use anything we want but I want to make the best decision in terms of scale (what if we need more than one server for data access) and ease of use for the other coders on the team. – Chris911 Feb 11 '14 at 4:40
1

I am not an expert of scaling applications, but I'll try to answer your question at least partially.

REST has 3 constraints which are about scalability:

  • stateless constraint

    You have to maintain sessions on the client side and on server side you have to authenticate every single request. So you can easily use multiple servers, because you don't need a shared session storage.

  • cache constraint

    You have to send cache headers with every request. So your clients can cache the cacheable responses and so they send less requests.

  • layered system constraint

    Your system components cannot see through the boundaries of the single layer they are in. The upper layer uses the services of the current layer, and the current layer uses the services of the bottom layers, and so on... So you can add load balance, cache, etc... between the client and the service, they won't recognize the existence of those components.

I think by translating REST to RPC the advantages of the layered system constraint are lost for nothing.

|improve this answer
  • RPC for some cases might be much faster, in exchange to losing some or all of the advantages. E.g. a connection to an SQL database, when used for multiple related requests, is an example of RPC that sheds the requirement of stateelessness but saves a lot of time on re-authentication. OTOH, an SSL certificate-based authentication with connection: keep might save reconnection costs for a REST interface: the caller will only re-auth (transparently) if the server it used to talk to closes the connection. – 9000 Nov 17 '14 at 20:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.