The range of these API is vast: almost every major player in web-delivered services now exposes large areas of their functionality through them. Google, Microsoft, Facebook, Amazon, eBay, SalesForce, Yahoo, PayPal, Wikipedia… the list could go on… a lot.
The OAuth mechanism
Access to such services obviously requires authentication and authorisation to prove that the owner/user of the data or services approves of allowing a given application to make use of, and possibly modify, them. Although there remains some support for user-name/password based authentication, most service providers now use (and only use) the OAuth mechanism, most commonly the current version of the protocol: OAuth 2.0. OAuth is described as a mechanism for providing “secure delegated access” to the owner/user’s resources. To quote Wikipedia, OAuth “specifies a process for resource owners to authorize third-party access to their server resources without sharing their credentials” – essentially users of an application can grant it access to their stuff without ever giving it their password (or other credentials).
For this reason support for OAuth 2.0 rather represents the “keys to the kingdom” in the business of integrating third-party RESTful services into your applications. The first step in getting your application to work with a given provider’s REST interface is to successfully manage their OAuth mechanism. This will usually involve first signing up and registering your application with the provider, in return for which you (the developer) will be issued with a “Client ID” (which uniquely identifies your application to the provider) and a “Client Secret” (sometimes called a “Key”) which are then used in the process of allowing the user/owner to grant your application access (frequently limited in both time and scope) to their resources via an Access Token.
Once this hurdle is overcome, performing operations on the API becomes simply a matter of making the appropriate HTTP calls, while providing the “Access Token” in each to prove that your application has the right to do so.
RESTful APIs generally make use of the HTTP verbs GET, POST, PATCH, PUT and DELETE to perform functions which are analogous to database CRUD (Create, Read, Update and Delete) operations. GET performs read operations, POST (and sometimes PUT) creates, DELETE obviously deletes, while update operations use PATCH (or sometimes POST). By far the commonest data interchange format is JSON, although some providers continue to support others such as XML.
The DataFlex REST APIs and OAUTH 2.0 forum
To help share and publicise OAUTH development for DataFlex, Data Access have created a forum for DataFlex developers (essentially web developers, since the mechanism relies on the use of a web browser and the DataFlex web framework).
See the REST APIs and OAuth 2.0 forum
Here you will find libraries which you can download and link to from your own DataFlex project workspaces, which will allow you to build these capabilities into your web applications. In addition, there are demonstration sample applications and links to documentation to help guide you through the whole process.
These capabilities are only available in versions of DataFlex starting with 18.1, because prior to that there was no support for HTTP verbs other than GET and POST. The UChar array functions, new in DF 18.1, also play an important part in handling the large amounts of data which can be involved in some operations, as well as providing a reliable mechanism for dealing with those that work with binary data.