{ DreamFactory: 'Blog' }

Don't Build Your Own REST APIs (Part 1 of 4)

Posted by Bill Appleton

Find me on:

Fri, Mar 27, 2015

The engineering team at DreamFactory designed and built some of the very first applications that use web services. Over the years, we made many mistakes trying to create the perfect API backend for these applications.

In our experience working with customers, we’ve learned that many companies face the same challenges we had to think about and tackle over the years. One of the biggest challenges is figuring out a winning API strategy. This blog post lays out some of the traps and pitfalls that companies often experience when they decide to build their own REST APIs.

When a company decides to start a new mobile project, they first develop the business requirements, and then start building the actual software. Usually there is a client-side team that designs the application and a server-side team that builds the back-end infrastructure. Assuming that the team decides that a RESTful approach is the best technical strategy, these two teams must work together to develop a REST API for the project.

The client team may be building a web-based application with AngularJS, Sencha, jQuery, or some other JavaScript framework. Or, they can build a native mobile application for iOS, Android. Or perhaps both. Hybrid applications might use PhoneGap or Titanium. Either way, they have plenty of work to do designing the user interface and coding the front-end application.

Meanwhile, the server team needs to identify the back-end data sources and external web services that the application will need for end-user collaboration and data access. They must develop single sign-on for user management, roles and access control permissions to back-end data, and a REST API that can securely expose the back-end assets to end users of the application.


This methodology creates an iterative development cycle as the client application is developed. The client team specifies various new REST API services that they need, and then the server team has to build the services, after which the integration must be tested for performance and functionality. This back and forth interface negotiation consumes lots of time and money as the two teams converge on an acceptable REST API.

The Tower of Babel

Building your own REST API is not just expensive and time consuming. In the example discussed above, the client team and the server team do eventually manage to get their application working as designed. But the real trouble starts when the next mobile project enters the picture.

As new mobile projects come along, they typically have new requirements that were not anticipated by the existing REST API services. You could go back and try to expand the scope of the old services, but they are already in production, and so in many cases new REST API services are created for each new project.

The modern enterprise may need hundreds or even thousands of mobile applications. And so the API building process continues over a few years with different developers, consultants, and contractors. Some of the teams are great at writing REST APIs, others not so great. Teams use different security mechanisms, credential strategies, user management systems, and API parameter names. Each service is hard-wired to specific data sources located in various clouds and data centers.

The result, as you can imagine, is a giant mess. Data access rights are confused, user management is complex, and application deployment is cumbersome. The system is difficult to manage, impossible to scale, and probably full of security holes.


The mistake here is that development activity started with business requirements and application design and then worked backwards to server-side data sources and software development. Instead, it’s better to invert the approach to architecting the interfaces: first identify the data sources that need to be accessed by mobile applications and then create a comprehensive and reusable REST API platform that supports general-purpose application development.

Many of these problems disappear as soon as a company adopts a REST API platform strategy. There is no need to keep building server-side software for each new project. RESTful services are no longer tied to specific pieces of infrastructure. Applications can be moved between clouds or from testing to production with ease. Client-side application design is decoupled from security and administration. Development expenses and time to market are dramatically reduced.

In Conclusion

The exploding complexity of backend interfaces is a real problem for companies building mobile and web applications or just using REST API services. My next blog post covers some of the potential solutions to this problem.

Read part 2 of 4 in this series, "Band Aids Don't Solve REST API Complexity."


Get started with DreamFactory with a free hosted DreamFactory development environment. Or, download and run it on the server, cloud, or desktop of your choice.

REST API Mobile Apps API Enterprise Applications

Weekly Digest

Recent Posts