Is it a bad choice to consume the REST API from the back-end too?

Question

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?

Answer 1

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).

Answer 2

I think the overarching justification out of making data access a RESTful API would be the relationship the data access would have to the rest of the environment.

Think about it, the power of the API is typically the vast amount and variety of "client" implementers that can consume it. That should be no different in your case.

In other words, if you were to have multiple consumers and different invokers of this same data access and/or looking to scale that out, then I think it would make sense.

But conversely, if you have a single consumer and this data access and logic is tailored very specifically so it doesn't scale, I don't know what you would gain out of making the transfer of bits through a RESTful API.

Answer 3

Not necessarily. Middleware cannot handle everything. There are three examples I always bring up to show this: batching, forwards and api chaining. These all benefit by staying within the bounds of the original request but in applications, often have to leave and come back in via the proxy/api gate.

By abstracting I/O from the api and moving it to an interceptor, you can use a prehandler/posthandler to hand off the communications and use one thread to handle the loop.

The the I/O flow from api gate to application instance to response tooling is one constan flow and isn't broken.

See api abstraction and api chaining for more information (http://www.slideshare.net/bobdobbes/api-abstraction-api-chaining)

Answer 4

Using the REST API from the backend has two advantages: You don't have to develop and document another API, and you only have one set of bugs, not two.

There are two possible objections: It could be that your backend does things that don't fit in with the existing API (because it may look at the data from the opposite direction as the frontend API does). And there might be performance issues: If the backend uses the database ten times more than the frontend does, and that is performance critical, then you don't want the simplest API, but the fastest.

So check how your backend will use the database and decide from there. If your backend is happy with the REST API functionality and there are no performance problems, use the REST API.

Answer 5

A lot of good answers and comments. To me, it seems microservice oriented. The challenge is that there is slight overhead inserting a layer between your data access and the backend code that churns on that data. Overhead in terms of development time & cycles, and overhead in terms of code performance. But the upsides are that your application components are more loosely coupled so you can extend/change the code with less complexity. If everything that accesses the data does so through the API, then any changes you need to make to the underlying data model if you make the API handle seamlessly then you are done.

On the contrary, if several parts of your code are accessing the data in several spots, you have more to consider and do and test. Also, when there are multiple places where backend code accesses the data, there tends to be inconsistency.