title: Erlang/OTP architecture: RESTful protocol for SOAish services
body: <p>Let us imagine we have an orders processing system for a pizza shop to design and build.</p>
  
  <p>The requirements are:</p>
  
  <p><strong>R1.</strong> The system should be client- and use-case-agnostic, which means that the system can be accessed by a client which was not taken into account during the initial design. For example, if the pizza shop decides that many of its customers use the Samsung Bada smartphones later, writing a client for Bada OS will not require rewriting the system's API and the system itself; or for instance, if it turns out that using iPads instead of Android devices is somehow better for delivery drivers, then it would be easy to create an iPad client and will not affect the system's API in any way;</p>
  
  <p><strong>R2.</strong> Reusability, which means that the system can be easily reconfigured without rewriting much code if the business process changes. For example, if later the pizza shop will start accepting payments online along with accepting cash by delivery drivers (accepting a payment before taking an order VS accepting a payment on delivery), then it would be easy to adapt the system to the new business process;</p>
  
  <p><strong>R3.</strong> High-availability and fault-tolerance, which means that the system should be online and should accept orders 24/7.</p>
  
  <p>So, in order to meet R3 we could use Erlang/OTP and have the following architecture:
  <img src="https://i.stack.imgur.com/UBBBn.jpg" alt="Pure Erlang/OTP architecture with one RESTful API entry point"></p>
  
  <p>The problem here is that this kind of architecture has a lot of "hard-coded" functionality in it. If, for example, the pizza shop will move from accepting cash payments on delivery to accepting online payments before the order is placed, then it will take a lot of time and effort to rewrite the whole system and modify the system's API.</p>
  
  <p>Moreover, if the pizza shop will need some enhancements to its CRM client, then again we would have to rewrite the API, the clients and the system itself.</p>
  
  <p>So, the following architecture is aimed to solve those problems and thus to help meeting R1, R2 and R3:
  <img src="https://i.stack.imgur.com/riGfh.jpg" alt="Service Oriented Architecture with multiple RESTful API entry points"></p>
  
  <p>Each 'service' in the system is a Webmachine webserver with a RESTful API. Such an approach has the following benefits:</p>
  
  <ul>
  <li>all goodness of Erlang/OTP, since each Webmachine is an Erlang application, which can be supervised and can be put into an Erlang release;</li>
  <li>service oriented architecture with all the <a href="http://en.wikipedia.org/wiki/Service-oriented_architecture#Benefits" rel="nofollow noreferrer">benefits</a> of SOA;</li>
  <li>easy adaptable to <a href="http://kinderman.net/2010/06/23/approaching-pure-rest-learning-to-love-hateoas" rel="nofollow noreferrer">changes</a> in the business process; </li>
  <li>easy to add new clients and new functions to clients (e.g. to the CRM client), because a client can use RESTful APIs of all the services in the system instead of one 'central' API (Service composability in terms of SOA).</li>
  </ul>
  
  <p>So, essentially, the system architecture proposed in the second picture is a Service Oriented Architecture where each service has a RESTful API instead of a WSDL contract and where each service is an Erlang/OTP application.</p>
  
  <p>And here are my questions:</p>
  
  <ol>
  <li>Picture 2: Am I trying to reinvent the wheel here? Should I just stick with the pure Erlang/OTP architecture instead? ("Pure Erlang" means Erlang applications packed into a release, talking to each other via
  gen_server:call and gen_server:cast function calls);</li>
  <li>Can you name any disadvantages in suggested approach? (Picture 2)</li>
  <li>Do you think it would be easier to maintain and grow (R1 and R2) a system like this (Picture 2) than a truly Erlang/OTP one?</li>
  <li>The security of such a system (Picture 2) could be an issue, since there are many entry points open to the web (RESTful APIs of all services) instead of just one entry point (Picture 1), isn't it so?</li>
  <li>Is it ok to have several 'orchestrating modules' in such a system or maybe some better practice exists? ("Accept orders", "CRM" and "Dispatch orders" services on Picture 2);</li>
  <li>Does pure Erlang/OTP (Picture 1) have any advantages over this approach (Picture 2) in terms of message passing and the limitations of the protocol? (partly discussed in my previous similar <a href="https://stackoverflow.com/questions/11173252/soa-why-do-not-use-erlang-otp-web-servers-as-services">question</a>, gen_server:call VS HTTP RESTful calls)</li>
  </ol>