While researching RESTful API frameworks I've come across (generally speaking) two types of frameworks:

  1. The first type will (more or less) directly (or nearly directly) map an ORM/ODM scheme of your database to the resources. For example, tbone.

    It does give you options for what fields to expose, as well as the ability to create expose faux fields (e.g. being able to convert an obscure DB enum value to a human readable phrase).

  2. The second type provides the ability to easily define your resources, but you have to fill in the details of what a GET to /users actually does. For example, Flask-RESTful.

The first approach does offer the ability to get up and running faster, however, I have several concerns:

  1. It seems like you're more locked in. With robust enough tests you'd likely be able to replace the framework but seems risky.
  2. Are there any security concerns with giving near direct access to the database or names of fields?

Is it safe to use these sorts of frameworks? Or is it a better idea long term to write your APIs from scratch?


  • This is going to depend on your domain. Are you writing a brokerage account system, or facebook for cats? Jan 22 '19 at 5:06

It's fine to use frameworks as long as you don't tightly couple any application-specific logic to them. If all you need to do is map database fields to a REST API, and someone's already done that for you, there's no need to reinvent the wheel.

If you ever start writing significant amounts of custom code to encapsulate business logic, you want to make sure that code is independent of any frameworks and you have a thin glue layer between your code and the framework. That way, if you ever decide to switch to a different framework, you only have to rewrite the glue layer.

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.