SOAP to REST
Tel +1 415-993-5877
START FREE TRIAL
START FREE TRIAL
How We Got Here
How We Got Here
by Bill Appleton
• April 25, 2013
Back before the turn of the century people started experimenting with new ways to make function calls across the firewall. Around this time in 1998 Dave Winer invented XML-RPC, which stands for Extensible Markup Language Remote Procedure Call. His specification introduced the concept of exchanging XML documents across a URL endpoint. The request and response would constitute a function call. These XML documents were normally exchanged with an HTTP POST transaction, and since this looked like regular web traffic the function calls sliced right through most firewalls. Tony Hong stated the XMethods website about this time, and soon there were many example services that could be called.
introduced an XML-RPC interface to their Customer Relationship Management database, and shortly thereafter they introduced a SOAP interface. This was what we needed: a complete services palette with pre-built objects. Salesforce also had an HTML interface that we could use for single sign-on and embedding the DreamFactory Player. When salesforce launched the AppExchange in 2005, we wrote the first third-party application, our DreamTeam Project Manager. We started to acquire new enterprise customers, and were funded in 2006 by one of the premier venture firms specializing in enterprise software, New Enterprise Associates. Over the next 5 years we published more than a dozen applications on salesforce, and also started working with other cloud platforms, including Intuit Partner Platform, Cisco Webex Connect, Amazon Web Services and Microsoft Azure. Our engineering team became extremely knowledgeable about what makes a good services platform, what the problems were at the client, and which ones worked the best. We also started building our own service platforms on generic cloud infrastructure for specific projects. And today we have 15,000 companies using our rich application products around the world. Along the way, we learned some very interesting things. First, there are a huge number of different applications that can be built if you have the right palette of services. By publishing rich applications on lots of different service platforms, we eventually discovered a very comprehensive and general purpose interface that supported generic application development. These service calls can be combined like LEGOs to build darn near anything. Second, our new development model was incredibly efficient. Once you have the right set of services, the server-side is baked. After that a small team or even a single developer can build and deploy an application without much support. You don’t need to write server-side software anymore, and the server team and the client team don’t have to discuss integration issues. This dramatically changes the time and cost considerations for building and maintaining an application. Third, the rich client model has huge relevance for the new world of mobile devices. Mobile networks are often quite slow and they can lose connection altogether when moving between zones. Rich client applications minimize network usage because only the data is shipped back and forth. And since the data transactions are atomistic and under client control, this model supports occasionally connected applications as well. Lastly, this model also saves money on the cloud. When business logic is moved to the client, the server becomes less complex and more agile, and this reduces the cost of hosting cloud infrastructure. Server-side page generation sends graphics, layout, scripting, and data across the wire with each user action or new screen. Moving to a service-oriented architecture can improve network performance by 90% or more, and this lowers the cost of mobile data plans. And so a few years ago, our engineering team started work on the DreamFactory Services Platform in an effort to bring these insights to a wider community of developers. Here are the design goals we set for ourselves: We knew that enterprise customers would need the ability to install our open source platform on their own cloud or data center. This way they could manage infrastructure, cost and security with familiar tools. We wanted to leverage our years of experience using service platforms and put together a comprehensive palette of services that was versatile, easy to use, and very powerful. This needed to include a direct connection to a dedicated SQL database. We put special emphasis on HTML5 support with native JSON documents. We think HTML5 is emerging as the right choice for enterprise applications. Companies need to support any device, and they don’t really need the app store for distribution. We wrote an Admin Console to make platform management a breeze. Our Admin Console is an HTML5 application written in Angular JS that simply calls our own services. And that’s how we got here. The first version of the DreamFactory Services Platform will be available on April 30th, 2013. Where we go next is up to you.
Never miss out on the latest API tips and news.
Join the DreamFactory newsletter list.
Glances & DreamFactory Partnership
What is Serverless Computing?
How Do You Test a SOAP and REST Service?
Oracle Database & DreamFactory
PostgreSQL vs. MySQL
There is no biographical info about this author yet.
Getting Started Guide
2020 DreamFactory Software Inc. All Rights Reserved