Clarifying when to use which API for Content Server

HFCDev

Hi,

While attending the partner deep dive event in Waterloo this week, I asked and got some answers to the question of when to use which customization methods. I'm posting here with the intent that Open Text will clarify that I've understood correctly, and elaborate on where I'm vague, and correct where I'm flat out wrong:

CS REST API: Used to build simple custom user interfaces to Content Server. Use the CS REST API (version 1) when there is only Content Server (and not any other Open Text product), and your "application" is going to only be used inside the firewall. In theory, the REST API could also be used to provide simple UI enhancements to the Content Server UI, but the current difficulty is how to reuse the existing authentication to the core UI in your widget built on the REST API.

AppWorks Gateway: effectively surfaces the same UI mentioned above but also any REST API for other Open Text products (and potentially 3rd party products). Use AppWorks gateway when a) you need to do a "mash-up" consisting of data from more than just Content Server, but other services that have their REST API available through AppWorks, or b) you need to make Content Server data available outside the firewall.

Other integration methods:

• Content Server Web Services (aka Enterprise Web Services) - used for integrating applications to content server, but also useful for .NET developers building portals in ASP.NET
• Oscript via CSIDE - should only be used to add business logic to Content Server; should not be used to alter the Content Server UI (although there are times when we as developers are forced to do this).

The last two integration methods are not applicable to mobile development which would be either of the two previously mentioned, although I would imagine that a mobile platform would likely need to be served from outside the firewall, meaning AppWorks is probably the only method mentioned here that should be used for mobile applications. Once again, I'd love for Open Text to vet this post to make sure I have understood all of this correctly.
-Hugh

Ferdinand Prantl

Your understanding is correct, maybe biased for the mobile application development specifics. While some general guidance of the API suitability can be given, the concrete scenario may not fit exactly and go for other API. It is easier to answer a question posed the other way round: If I do this, what API fits the best? For example: I write a plugin for a Windows Service, which synchronizes files with various servers - use the CS SOAP WS. For example: I write a HTML page which shows the most recent 5 documents added to my project folder - use the CS REST API.

Client APIs

They are to be consumed by a remote client; not executed from within the CS.

CS REST API is consumed the best by applications written in free-typed (scripting) languages. JavaScript, Ruby, Python etc. Web browser applications and command-line tools, for example. The development framework is lightweight and usually lacks support for protocols like SOAP.

CS SOAP WS API works best for applications written in strong-typed languages which include tools generating the service proxies for you. Server-side integrations, B2B communication, for example. The development framework aids you to write the code ensuring the maximum robustness by checks on multiple layers.

LAPI is an RPC-style API used for earlier versions of the Livelink server. It has been deprecated and no improvement is planned; except for critical bugfixes probably. Do not use it for new applications. If you maintain an existing mature application, keep "milking" it. It's usually not worth just replacing the API. New applications usually need a different design (support for mobile devices) and you'd probably use this opportunity to give your application a major overhaul; not only to replace the API.

Server APIs

They are used to write applications running in the CS. They usually offer some client API to report about their activity. They are written in OScript and deployed as modules on the server. DAPINODE, LLNode, CSNode, WebNode are objects you would work with and you'd learn about them from the Builder SDK available at the OT KC. You'd use them to develop your (REST) APIs to be consumed by your application UI.

Web Development

Traditional web applications have been made on HTML pages generated the server: WebLingo (OScript) ASP.NET (.NET), JSF (Java). You usually used SOAP WS to communicate with other servers. Modern web applications run in JavaScript within the web browser and perform just data communication to the server when neded. You usually use REST API for this.

Mobile Development

You can develop an application running in the mobile web browser with the CS only - HTML/CSS/JS/OScript. Products like ActiveViews offer mobile support for the CS pages. However, you will gain more flexibility when writing your application in HTML5/JS using some browser application framework and connecting to the server by the CS REST API. You decide about the framework depending on your requirements. Does your application have to run on all mobile, tablet and desktop devices? Or does it have to run on cell phones only and look exactly as the device OS? Backbone & jQuery Mobile, Sencha Touch etc. or native application?

When you choose the framework, you can think about the deployment of your application. From global services like AppStore, Google Play etc. or from a private company server? AppWorks is a great way to distribute and manage your application on mobile devices for your company employees, including the data security. It offers an SSO for other OpenText products (based on the OTDS) and a reverse proxy to access REST APIs behind a firewall.

Customizing CS UI

It you need to extend the traditional CS page and not to develop an alternative UI, you may be the most efficient using the WebLingo/OScript development on the server side. The CS has provided components and hooks for it for a long time. There are products like WebReports and ActiveViews which hook on the server side to the page generation to customize the UI. However, the requirements nowadays ask for dynamic applications and mashups from different sources, usually run on different portals or mobile devices, that's why the trend goes the way of REST APIs provided by the server and multiple scenario-specific lightweight UIs.

CS REST API on CS pages

The CS doesn't provide you with the ticket for the REST API on every CS pages today. But it is quite easy to put the ticket on the pages where you need it on your own, because you partially work on the server side anyway. It may improve in the future.