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