Dan’s Dev Corner – March 2018

*This is a guest blog, written by SeeUnity CTO, Dan Hunsinger

A few months ago I wrote a little about our new Content Web Services component.  It’s a new web service that uses the latest Microsoft IIS technologies to support remote Core Integration Service (CIS) servers, remote client access, and mobile access.  Now, it’s been extended to support a full REST API for programmatic access to SeeUnity connectors.

The REST API follows all the common conventions found in most of the modern HTTP-based APIs:

• Uses token-based authentication. A username and password are sent to the server and an access token is returned to the client. That token is sent in the authorization header for most calls to the REST API.
• Can send and receive either JSON or XML for most calls.
• Create and check-in documents with meta-data as multipart/form-data.
• Well-defined endpoints for connectors, folders, and documents.
• UTC format for date fields.
• Versioned API to support incremental updates without breaking existing applications. A sample URL request is:
  • http://<server>:<port>/api/<apiVer>/<endpoint>/<eid>/<action>

We’ve always had a virtual API that is used by other SeeUnity components such as Echo, Fusion, Velocity, and Vortex as the primary way to interact with the various repositories that we support.  This has allowed us to develop solutions that can easily extend to multiple systems without too much repository-specific code.  For example, to get a list of items within a container a single API is called, whether the container is actually a folder, quick search, workspace, saved search, dynamic view, cabinet, etc. With the REST API, we’ve extended the virtualization model even more in the following ways:

• Common fields for things like name, created date, last modified date, created by, last modified by, and the like are normalized as one set no matter what the underlying system is.
• A common model for versioning (major/minor) is supported and includes common calls for checking in and checking out a document.
• We’ve fine-tuned a lot of the existing virtualization based on years of experience in dealing with different repositories.

Essentially what we’ve done with the REST API is take the repository virtualization model we’ve had in place for several years, reformulate it as a modern REST-style interface, and extend the virtualization model even further so that it’s even easier to write code one and use it against most document management systems.