In a previous blog, I showed how to develop microservices to connect to Autonomous Databases and consume data (read/write) via REST APIs. Although I still highly recommend that approach, the reality is that there is an easier way to do it using Oracle REST Data Services modules that come included with any Oracle Autonomous Database (ADW/ATP).
This way you simply have to:
Configure the API endpoint (Method + URL) that you want to expose as a REST API
Define the underlying SQL statement that will serve to your endpoint (i.e. SELECT, INSERT, UPDATE, DELETE statements or a more complex PL/SQL script)
Define the security mechanism to properly protect your APIs
That’s pretty much it, this should be a very quick, yet powerful alternative to building your own microservices to consume data from Autonomous DBs.
Oracle’s Cloud Infrastructure has been designed in an API-first manner, which is awesome for all sorts of infrastructure automation tasks. It also implements an interesting API security model, in which all requests must be signed using a private key, associated with a public key which has already been configured in OCI (here, the developers are showing their infrastructure roots, as this echoes how SSH Auth is normally handled). The documentation of this model provides sample code in a number of languages, which is perfect if you are writing automation scripts, but is a little inflexible for ad-hoc testing. Typically I much prefer to use a rich graphical REST client, such a Postman, so that I can easily tweak my parameters and try out different types of calls before I write any code. Unfortunately while Postman is well equipped for Basic and Token based Auth, HTTP-Signature is not natively implemented, and rather than abandon Postman for a new tool, I set out to implement it using Postman’s powerful scripting capabilities. In this blog post I provide the result of this, which is a downloadable collection which provides all of the required scripts, and discuss the approach used.
Recently I built a Facial Recognition Mobile App using Oracle Visual Builder having set up the Facial recognition APIs using Tensorflow taking some inspiration from FaceNet. As highlighted above the app does the following: record a video of your face and send it to the API that generates various images and classifies them based on the label we provide at runtime. And in turn, invoke another API that is going to train the machine learning model to update the dataset with the new images and label provided. These two APIs will build a facial recognition Database. Once I have this, I can capture the face and compare that with the dataset I have captured earlier in my Facial recognition Database to output if the face exists in our system.
Here is a quick cheat sheet if you ever wanted to build a mobile app that can take advantage of the camera built into the device, capture the vehicle or vehicles nameplate(s) in a frame and process that image and send it on API that can analyze the image and relay back the information it just scanned. This app can be extended to fulfil requirements like checking if the vehicle registration is up to date or insurance renewal is overdue etc. provided if there are APIs already available that can deliver this information.
So what is the tech involved in building this app?
To build a mobile app that can be deployed on iOS or Android, I used the Visual Builder service from the Oracle Cloud stack. This service provides the capability to build Web as well as Mobile applications through a declarative approach with the ability to introduce code for any complex requirements.
To store the captured image and use the image for downstream application purposes I used the OracleContent & Experience service that comes with a rich set of APIs for content ingestion, public document link generation etc. From an enterprise architecture viewpoint, it makes sense to store the images with metadata in a content store, so I decided to archive the image using this service as part of the mobile app build process.
The most significant bit is to use a library / API that can process the image or OCR and send back the information we are interested n. For these purposes, I used the open source ALPR library. There are API’s available already if you want to fast track your app.
This one is optional. If you want to validate the information captured, we can set up a few API’s using the Oracle Autonomous Database with some data to complete the validation flow in the app.
In November 2018, I had the privilege to attend the Australian Oracle User Group national conference “#AUSOUG Connect” in Melbourne. My role was to have video interviews with as many of the speakers and exhibitors at the conference. Overall, 10 interviews over the course of the day, 90 mins of real footage, 34 short clips to share and plenty of hours reviewing and post-editing to capture the best parts.
In this blog, I am going to show you how to build a nice and simple UI with data coming from invoking REST APIs. All without code, but in just a few clicks.
I consider myself a good backend developer, good at making things functional, but I really struggle every time I need to produce nice UIs. However, using Oracle Visual Builder, I feel like I don’t have to be a UI developer or designer, I can very easily produce nice and friendly mobile UIs that consume my backend REST APIs. If you are like me, a backend programmer who loves API-first design approach, I’m sure that you will find this blog not only informative, but also refreshing.
This is a quick view of what we are going to achieve in this article:
First, we are going to auto-create Service controls in Oracle Visual Builder by pointing to existing REST APIs.
Then, we are going to use the out-of-the box widgets and components to build a simple, yet powerful UI that consumes such APIs.
Finally, we are going to publish the UI and test it across different media, e.g. Web on a laptop, mobile, tablets, etc.
In a recent blog post, I added a throwaway reference to the use of signed assertions as a better mechanism for interacting with the Oracle Identity Cloud Service REST APIs than the use of Client id/secret, though qualified it with ‘if you want to handle the additional complexity in your consuming client’. Reflecting upon this, I thought that perhaps it was worth trying to explain this ‘additional complexity’, since the use of signed assertions have a number of benefits; primarily that it does not require an exchange of sensitive information, as the private keys used to sign the assertion never need to leave the machine on which they are generated. In this blog post, I will delve deeper into what is required to leverage this authentication mechanism, for both clients and users.