A little over a month ago, we announced version 4.0.0 of DADI API, one of the most significant updates in the history of the product. We hadn’t even finished our celebratory (virtual) beer and we were already hard at work, preparing the next set of features and improvements. Here’s what we’ve been up to.
🔗Multi-language support
Version 4.0.0 was focused on bringing the product closer to the end user, creating a viable alternative to the traditional machine-to-machine interaction that previous versions used to favour. The access control list was just the first of a series of high-level features we want to add to API. The next one was internationalisation.
Since version 4.1.0, you can translate fields into multiple languages and specify the language that you want your documents in. Whilst it was already possible to build this type of functionality with user-defined logic using hooks or custom endpoints, making it part of the core product makes multi-language documents a first-class citizen in API.
Further improvements and integrations with other products, such as Web and Publish, are currently in the works.
🔗Document search
The latest version of API also introduces one of the most frequently requested features: document indexing and search. It is now possible to specify within a collection schema which fields should be indexed, and API will index each document as it is inserted or updated via the collection’s endpoints.
Once indexed, searching for content in the API is as simple as querying a collection’s search endpoint - matching documents are returned to the client in the same format as a response for a standard GET request.
🔗Custom client data
We envision API as the brain of the DADI suite of web services. Armed with its fully-fledged access control list, it is a good choice for managing all the authentication and authorisation requirements of your web or mobile application. In such a scenario, it becomes important to be able to store additional metadata alongside a client record, like personal details or application-specific preferences.
Since version 4.2.0, you can do just that. There’s even support for read-only properties, ideal for data that you want clients to be able to read but not tamper with.
🔗New client endpoints
When another application authenticates with API on behalf of a user, it may persist the resulting access token for subsequent requests, as opposed to requesting a new one each time. Depending on how it is built, the application may find itself in a state where the access token is the only information it has about the client, being oblivious to other key details like the ID of the associated client.
Since version 4.2.0, a new set of endpoints allow a client to obtain and update information about themselves by simply having an access token.
🔗Feature queries
As the feature set of DADI API evolves, it’s possible that two instances running different versions of the product have support for substantially different sets of functionality. Since consumer applications may require a specific feature in order to operate, it becomes essential that applications have a view on the capabilities of the API instance they communicate with. For security reasons, API does not expose its version number, but since version 4.2.0 it allows clients to enquire about whether a particular feature is supported.
In practice, this means that consumer applications can adapt to the capabilities of the API instance, gracefully handling errors or downgrading functionality if the API capabilities are below the minimum requirements. You can read all about feature queries in our documentation hub.
🔗That’s all – or is it?
It is for now, but work for the next release is well under way. A more powerful validation system, new field types and further enhancements to the ACL layer are some of the things we’re cooking.
In the meantime, you can update your existing installation to version 4.2.0 or spin up a fresh instance if you’re new to the family.
