title: Using REST API as server side for web page application
body: <p>We have web applications that we build internally (server side exposes web-services that are called from client side JS).
  We also required to expose our code functionality in REST API.</p>
  
  <p>I wonder - should I also start to use the REST API also for the web application that I build internally?</p>
  
  <p>Originally, the REST architectural style declares that the REST is stateless (<a href="http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_3" rel="nofollow">http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_3</a>). This results in consumers\clients that keeps the state in the client side.
  It works well for "rich" clients (mobile applications, etc...) that are built to save the state in their side. But... is it the same for web applications?
  Is it good to have server side that expose itself in REST API, and the client side calls those REST API directly?</p>
  
  <p>I see some pros, and some cons.</p>
  
  <p>Pros:</p>
  
  <ul>
  <li>Unified interface - our server side exposes it's API only in one way (REST), for the web  application, and for general purposes API</li>
  <li>Easy to expose services that we use internally to be used by external users.</li>
  </ul>
  
  <p>Cons:</p>
  
  <ul>
  <li>As said above - browsers are not built to save cache in the client side. </li>
  <li>If I have the possibility to use state - why not? It improves performance (less back and forth), and ease on development.</li>
  <li>Once we expose the internal API to customers, it restricts us to be very careful with the changes.</li>
  </ul>
  
  <p>Any hints\recommendations?</p>