RAD Studio 11 saw the introduction of the TRESTRequestDataSetAdapter, a component that can read data from a TDataSet and convert it to JSON ready to send back to a remote RESTful API. Before I talk more about how to use it, I want to recap how REST URL/APIs work.
REST APIs and VERBS
REST APIs are typically created to use the different HTML verbs (POST, GET, PUT, PATCH, and DELETE) to define the type of request being made to an endpoint.
As an example, let’s imagine you manage a list of tasks in a database that are either complete or incomplete. A base API URL such as “https://<myURL>/data/tasks/” could provide an endpoint to call to work with the TASK data, and the different verbs are then used when calling the endpoint to define the type of action happening. (e.g. Fetching data, inserting, updating or deleting data). To make this work, certain verbs require an ID value to identify the data you want to work with (e.g. which record to update / delete?), so in reality, the URL for certain tasks would also take an optional ID value, e.g. “/data/tasks/{id}”
To send the data back to the server using the TRESTRequestDataSetAdapter, it’s firstly important to match the operation (insert, update, delete) to the correct verb, and then use the TRESTRequest to execute with the correctly formed JSON data, but also to ensure the endpoint has the correct endpoint defined.
Using this standard naming for URLs (above), plus the TRESTRequestDataSetAdapter, it is possible to packet the JSON with little code to send data back to the server. The TRESTRequestDataSetAdapter connects a TRESTRequest and a TDataSet. The Area property defines what is being selected (e.g. All or Current record), and converts the dataset into the JSON content that is required to be sent back to the server.
To do this automatically, you can use the events on the TDataSet, e.g. AfterInsert, AfterPost, and BeforeDelete, to pick up changes in the dataset and then make remote calls to keep the server in sync.
HOWEVER…. what if you have connection issues?
Benefiting from Native Development to make REST applications more feature rich.
One useful feature of FireDAC (and some other datasets such as TClientDataSet) is the CachedUpdate option. Using CachedUpdates you are able to keep track of changes inside a dataset. This allows changes to be cached, saved locally, and then pushed back at a later point in time. (great if there is limited connectivity).
It is possible to combine these great features of the native libraries along with the TRESTRequestDataSetAdapter to save changes back to the server. While this can add more complexity, especially when you have insert, update and delete operations combined in the same cache (as these use different VERBS to update the remote server), it is possible to filter a data cache to process each type of update in turn.
To show you how to do this, I’ve created an example that is available via GitHub – This includes a unit REST.RESTUpdater with help classes of manage transport and posting of data in only a few lines of code! – Learn more about the example on this post
Design. Code. Compile. Deploy.
Start Free Trial Upgrade Today
Free Delphi Community Edition Free C++Builder Community Edition