With the recent explosion in cloud-based legal technologies, law firms need help choosing the right ones. This article provides such guidance, with a focus on interoperability. Interoperability is critical because no single application can do everything. Instead, different technologies need to be integrated to provide law firms with complete solutions.
The Benefits of REST APIs
There is a lot of talk about REST APIs. An API, or “application programming interface,” allows two applications to share information and trigger commands against each other, which are often referred to as “requests” or “calls.”
REST, or “representational state transfer,” is today’s de facto API standard governing the interaction between cloud-based applications. Its primary advantage is that it uses the language of the Internet (aka “http”) and uses the same commands a browser uses when accessing web pages (like GET and POST). Because every cloud-based application accepts http commands, they can natively handle REST API requests too.
Because REST APIs are necessary for cloud-based applications to interact, and because applications’ ability to interoperate magnifies their value, offering a REST API should be a requirement for any firm or lawyer considering cloud-based applications.
REST API Support in Applications
The REST API standard was invented in 2000 but did not gain traction until 2005. Many legacy applications were introduced prior to the wide adoption of the REST API standard and, therefore, were not architected to support REST APIs.
As adoption of the REST API standard accelerated, and the value of interoperability grew, the lack of a REST API became a notable shortcoming in legacy applications. This forced established vendors to catchup and add support for REST APIs. But shoehorning a REST API into a legacy platform is nontrivial. It requires significant reengineering, which cannot easily be done all at once or comprehensively. A legacy application may perform 100 actions (like retrieving a file), but its REST API may be limited to 25 actions. To fill this gap, legacy vendors will often add REST API calls with each new release.
This is one area where newer cloud-based applications, typically, have an inherent advantage as they may be architected from the start to use REST APIs when performing most if not all actions; this makes their REST APIs more comprehensive.
Another REST API feature to consider is the format of the content that is sent and received. Today, JSON is the leading format, rather than XML.
As you evaluate any cloud-based application, determine whether the application offers a REST API, whether that REST API fully utilizes JSON, and how comprehensive the REST API is.
From an interoperability perspective, consider the primary uses that the application will serve. Can the application’s REST API actually accomplish all of those tasks? Ask a technical resource to review the application’s REST API documentation (lack of REST API documentation would be a red flag!). If you are piloting the application, include a real-world test of the application’s REST API calls, such as updating a document, deleting a record or triggering an email.
The Need for Speed
Another consideration when evaluating software is the need for other systems to respond to a large volume of activity generated from a source system in real time. Does your firm need changes from one system to propagate immediately to another? REST APIs alone are often not ideal at pushing information to other systems in real time.
Consider the situation where a new matter is added to a firm’s accounting system: how are the time and billing and document management systems notified? If we are limited to using REST APIs, that would require polling for changes against the accounting system for new matters on a schedule, then making calls on the other systems to insert any new matters. This approach is inefficient – often there will not be any new matters when a query is made – and results in delays. To minimize delays, the recurring query may need to run more often, which is even more inefficient and could cause system slowdowns if the number of queries is large.
The Benefits of Event-Driven Architecture
Enter event-driven architecture, in which a consuming application (the one that uses data from another application) can “subscribe” to a source application (the one that provides the information to the other application) and be notified automatically when activity occurs.
The need for event-driven architecture has grown due to the popularity of “bridge” platforms like Microsoft Power Automate and Zapier. These platforms serve as a bridge connecting multiple cloud-based applications, but only if those applications have implemented REST APIs.
These bridge platforms are most useful when a workflow can be triggered automatically by subscribing to external events from an application. For example, a Power Automate workflow can subscribe to a SharePoint list and be triggered when a new record is added. Otherwise, it needs to poll for new records itself on a set schedule.
Event-driven architecture is especially relevant now due to the rise of Microsoft Teams. To support its integrations, Teams relies on a type of event-driven architecture known as a “webhook.” If you require another system used by your firm to insert notifications and information into a Teams channel, then that system must be event driven.
Event-Driven Support in Applications
Webhooks are a relatively recent invention. The term “webhook” was coined in 2007. Legacy cloud-based applications are unlikely to have included event-driven features in their original design and will instead need to bolt those on later. And, just like REST API calls, making an existing application event driven is a large undertaking. Newer applications are more likely to be event-driven from the start.
As Teams moves to the center of a firm’s collaboration and communication strategy, the firm will benefit by integrating its cloud-based applications into Teams. Applications that are not event driven will be left out.
Therefore, when evaluating any cloud-based application, it is not enough for the application to (1) have a REST API that (2) is comprehensive and (3) consumes and produces JSON. Also ensure that the application is built on an event-driven architecture, which can likely be exposed via webhooks. Also be sure to consider your firm’s potential future needs. Some of these integration features may not be a priority for a solo practitioner, but if there is a plan to grow and have multiple lawyers making changes to systems, locking in to a legacy-based system may later create inefficiencies and result in wasted billable hours.
Mark Salamon
Product Manager
Jackson Lewis P.C.
Photo by Aleksandar Pasaric from Pexels
