30 Apr

Deploying MarkLogic REST API service extensions

Author: Dave Cassel  |  Category: Software Development

When you deploy a custom service extension to MarkLogic’s REST API, where does it go? By default, service extensions are put in the Extensions database. This means that an extension is available to all applications on the MarkLogic instance. While I can see use cases where this is helpful, the servers I work on typically have several completely independent applications. As such, I want my extensions to be in the same modules database as the rest of the application code. Happily, there is a simple way to accomplish this.

First off, let me note that I’m not sure of the MarkLogic version where the option presented below became available, but it was definitely available as of 6.0-2.3.

Properties

If you’ve been working with MarkLogic’s REST API, you’ve probably come across the directory structure for storing options: /<group-name>/<appserver-name>/rest-api/. There’s an options directory there to control searches, but right in rest-api (of App Builder or Roxy Hybrid and REST applications), you’ll find a file called properties.xml. This file set options that control the behaviour of the REST server. One of these properties tells the server where to putservice extensions.

<map:entry key="can-copy">
  <map:value xsi:type="xs:boolean">true</map:value>
</map:entry>

When set to false, extensions go to the Extensions database. When true, they’ll go to your modules database.

There’s an important caveat: deploying the change in this property is necessary but not sufficient for the change to take effect. Because the server stores the value in memory, the MarkLogic instance needs to be restarted.

Why Do We Care?

Here are some reasons I want my extensions in my application-specific modules database.

  • Avoiding conflicts. Maybe you want multiple applications to use the same extension. If you do, and then you update the extension, that’s an impact on every app that uses it.
  • Imports. If the extension depends on other libraries, those libraries need to be deployed to the same database as the extension.
  • Backups. If your app lives in your modules database, a simple back up captures all your code.
  • Security. You might have an application where you’re comfortable exposing the REST API to the public. Are you also okay exposing all the service extensions? Tough to answer when extensions can be independent of your application.

There are ways to address each of these concerns while still using the Extensions database, but it’s much easier if you don’t.

 

Tags: , ,

Leave a Reply