Using a REST API for front-end code is a desiderable and quite common practice.However, I was wondering if using it also for the back-end could be a good choice.What I mean is leaving the burden of retrieving data from the database all to the API, and then call it from other parts of my back-end (mainly views and controllers) whenever I need to query the database, instead of doing it directly.One thing I'm really concerned about is sharing some code between front-end and back-end, and using the API as a common source of data would be very handy.So the question is, are there some reasons which make this a bad idea?
Is it a bad choice to consume the REST API from the back-end too?
architecture;rest;api
Decoupling components from the database / getting away from direct database connections is a common pattern. Moving access into middleware / a component that front-ends the database can help improve security and modularity, and provide a place to implement data validation and interpretation that would otherwise fall into SQL, stored procedures, and client-side database code. Against this you have to weigh the development, runtime, and possibly economic cost of that middleware / data mangement front-end. But at many project scale-points, data front-ends are often considered a good choice. If you control the backend design and components, using a RESTful API--especially in its common format, e.g. served by HTTP and encoded with JSON--is notably inefficient compared to other alternatives (e.g. direct library linking, Protocol Buffers, Thrift, various kinds of ESB, other RPC mechanisms, ...) that do not go through a serialize-to-text, serve, deserialize-from-text cycle for every API call. REST is also semantically better as an arms-length interaction mechanism, given that some constructs (e.g. multi-step transactions, streaming, large binary objects, raising exceptions, guaranteed delivery, ...) are more simply, cleanly, or directly handled with other forms of interaction. Some reasons you still might want to use a RESTful backend: simplicity, consistency (every client, local or remote, goes through just one API), and time-to-market (e.g. not needing to learn another API/interaction style). These assume that you are exposing your database, relatively directly, through the RESTful API. If it is strictly for the use of components under your control, REST is probably not the best choice (for either semantic richness or efficiency). 