Foreword

Written by Jim McKeeth

Chief Developer Advocate & Engineer

Embarcadero Technologies

Everyone knows Delphi is the best solution for connecting to databases and building mobile and desktop applications. The Delphi MVC Framework (DMVCFramework) brings the amazing productivity of Delphi to the web!

The DMVCFramework is based on Delphi’s WebBroker module, which was introduced in Delphi 3 back in 1997. A lot has changed since WebBroker first appeared, both with Delphi and with the web.

The First Web Browser War began in 1997. Microsoft just released Internet Explorer version 4 and left a ten-foot-tall letter “e” logo on Netscape’s front lawn, with a “From the IE team …We Love You,” sign attached. After the Netscape employees knocked it over they returned the favor with a Mozilla dinosaur mascot holding a sign reading “Netscape 72, Microsoft 18,” the browser market share at the time. Opera, Apple’s Cyberdog, the Lynx text-only browser, and others made up the remaining 10%.

As the web evolved we see the rise of XML and SOAP web services. Both XML (Extensible Markup Language) and HTML (HyperText Markup Language) are based on the Standard General Markup Language (SGML), which is the source of the angle brackets. SOAP is the Simple Object Access Protocol that allowed for Remote Procedure Calls (RPC) and promised a decentralized collection of remote services easily invoked via web requests.

Delphi got it’s XML based SOAP Web Services in 2001’s Delphi 6. It added both the ability to build XML SOAP Servers and consume existing XML SOAP services, even those built with other tools. I contributed a chapter to a book on building a web-based SOAP Client that consumed a .NET SOAP Services. It used Kylix to deploy the Delphi web server on Linux.

SOAP never realized its dreams of revolutionizing the way services were called, only ever receiving limited adoption. Things changed again when Roy Fielding introduced the term representational state transfer (REST) in his doctoral dissertation. Where XML SOAP was a heavyweight officially adopted protocol, the new REST challenger was lightweight and vague. Really more of a descriptive recommendation.

REST is built on the simplicity of the HTTP protocol. This allows for a regular web browser to view a simple REST endpoint. The resulting data is typically in JSON (JavaScript Object Notation made up of curly braces), but the data is returned.

Further, a service is considered RESTful if it meets the following architectural constraints:

1. Uniform interface - REST makes use of the Uniform Resource Locators (URL) standard of the web to define endpoints as the interface of REST
2. Client–server - This is all about separation of concerns, and the improved scalability that comes with it. The data storage and the user interface are decoupled and allowed to evolve independently.
3. Stateless - This requires that each request must contain all of the information necessary and cannot take advantage of any stored state. So two identical requests will produce the same identical response. This allows for greater horizontal server scalability. Many rest implementations do allow of an authentication token to maintain a session, but beyond that, it is important that the order of requests does not impact the results.
4. Cacheable - Since it is stateless, it is easily cacheable. If you request a specific page of data, then that same request will always return the same results (until the data is changed). A non-cacheable system may automatically give you the next page on future requests, but it wouldn’t be stateless either.
5. Layered system - This is where the popular term “microservices” comes from, with the idea that a RESTful service architecture is made of multiple layers of REST services, each only aware of its neighboring layers.

Finally, with REST we see the realization of a distributed and open web services architecture. Most every site that offers a service makes it available via a RESTful API.

What is the Delphi MVC Framework, and why does it matter?

MVC is a design pattern all about decoupling the Model, View, Controller to make it easier to build an application where the user interface (view) is independent of the data (model) and functionality (controller). This makes it easier to create a multi-tier application with multiple user interfaces: web, mobile, desktop, etc.; that all use the same backend. The user observes the view, interacts with the controller, which manipulates the model, updating the view. (See Figure 1)

With the DMVCFramework this is expressed as a REST-based web service. The controller is made up of the REST endpoints that provide the functionality to manipulate the model or data (usually a database, but not always), then the view is the REST endpoints that provide the data to the user. The advantage of this decoupled pattern is the view is just as easily implemented through a web page as through a mobile or desktop application. They all just call the REST endpoints.

DMVCFramework is one of the most popular frameworks for building web applications with Delphi. It includes full support of RESTful (RMM Level 3) JSON-RPC 2.0 APIs making the building and publishing as simple and flexible as possible. It isn’t the only REST Server solution for Delphi, and that is one of the things I love about Delphi: the variety and choice available to the end-user.

If someone were to ask me which REST Framework to choose, I would always tell them it depends on their implementation and requirements, but if you are new to building a REST Server solution, then the DMVCFramework is a great place to start. As an open-source project, the barrier to entry couldn’t be lower, especially with the availability of this book. You may find it is the perfect solution for you.

-Jim McKeeth

Chief Developer Advocate & Engineer

Embarcadero Technologies

jim.mckeeth@embarcadero.com