Multiple Performant Operations with the New Adobe Document Services REST APIs

A few weeks back, we covered the release of our new REST APIs for working with Adobe Document Services. In that post, we explained how the APIs differed in terms of usage from the SDKs and talked a bit about why developers may choose to use them over the SDKs. In this post, we’d like to expand upon that by focusing on one of the core benefits — the ability to do multiple calls with just one file uploaded. Let’s quickly recap how the new API works and then go into how we can make use of this powerful new feature.

The New REST API Architecture

At a high level (and be sure to read the introductory article for a deeper look) the APIs follow this pattern:

1. Generate a JWT using credentials.
2. Request an upload URL for an asset and upload to that URL.
3. Kick off a job, like an OCR operation.
4. Check the status of the job.
5. When the job is done, download the result.

The important bit comes in step 4. When we poll against the REST API, we get a status object, and when the status is done, it looks like so:

While you can immediately download the URL (using the downloadUri value), note the assetID. This represents the result of the operation and can immediately be used in other options. Let's take a look at that in action.

OCR and Compression

If you read the first article we wrote on the new REST API, you’ll remember that we built utility functions to handle all the parts of the process. This makes the rest of the code simpler. So for example, here’s just that portion, with the comments and most of the logging removed:

To perform multiple operations, we need to modify our existing pollJob logic. Previously it only returned the location of the result, but instead, we need the entire result, so let's start there:

You’ll see I’m now returning the entire asset block, here's an example of how that looks (which is pretty much the same as before, but minus the status):

With the assetID, we can immediately turn around and use it again! We’ve already got a createOCRJob function, let's build a createCompressJob:

We’re making this a bit simpler than what the actual API allows. So for example, we could support different compression levels as an argument. Check the Compress PDF API endpoint docs for more information.

But the important thing is that with this in place, we can now update our script to OCR and compress a PDF, all with one upload:

This is a pretty minimal change, but it shows the power of the new REST APIs and will greatly improve performance. You can find the complete source for this demo here: https://github.com/cfjedimaster/document-services-demos/blob/main/rest/multi.js

Document Generation — REST Empowered

Document Generation is a powerful API that lets you use Microsoft Word files as templates. You craft a template with tokens representing variables, conditionals, looping, and more, and then send that Word document to our API with your data. The result is a customized PDF or Word document. With the new REST-based architecture allowing for multiple operations, we can make use of this with Document Generation to allow for one upload of the Word template with multiple calls just containing the custom data. Here’s an example.

First, let’s craft a very basic Word template:

The template uses three variables, name, company, and class. Let's look at a script that makes use of the new architecture and the Document Generation API.

First, we’ll define variables that point to our Word doc and specify the media type:

Now, let’s define our data. This is hardcoded but could come from any source:

We need to upload the Word document as an asset, and this follows the same pattern as before:

Now for the fun part. We’re going to loop over our data, and for each, create a document generation job and download the result:

We begin by creating a dynamic name for the result based on a loop iterator. For each item in our data array, we call a new function, createDocumentGenerationJob, and specify the existing uploaded asset and pass in the individual row of data. Once done, the file is stored.

Note that this code could be much more performant if we fired off the jobs all at once and then used the Promises API to wait for them all to complete. But even without that code, this is going to run quicker than what was previously supported as there’s no longer a need to re-upload the same Word document.

Here’s the createDocumentGenerationJob and as before, we've simplified it a bit. Check the docs for a full look at what's possible.

You can find the complete source here: https://github.com/cfjedimaster/document-services-demos/blob/main/rest/docgendemo_notfancy.js

Next Steps

Once again, if you want to give this a try, head over to our docs and hit up our forums with any questions!