Use of LAPI vs. Content Web Services vs. REST API

Hello all,

I'm looking to elicit feedback from the community regarding three external APIs into Content Server:

LAPI (Livelink API) -- available for many years, deprecated after 9.7.1
Content Web Services (CWS) -- first available in 9.7.1, continues to be available
REST API -- first available natively in CS 10.5 and optionally in CS 10

Your feedback will be used to help guide current and future development of our APIs for Content Server.
If you would rather respond to me privately, please feel free to do so via e-mail at kswidrov@opentext.com.

I have some specific questions depending on your role.
If you can provide some input here, indicating which role you best fit into, we would greatly appreciate it.

For the End User or Administrator

Do you still use and/or develop LAPI applications in your environment?
If so, are you able to change your applications to use either CWS or the REST API?
If not, what has prevented you from switching?

If you do not use LAPI in your environment, were you involved in an effort to switch old LAPI applications to a newer API?
If so, what issues did you run into?
Are there feature gaps between APIs that you are able to identify?

If you performed net new development using Content Web Services or the REST API, how did you choose which API to use?

Finally, what are your current upgrade plans for Content Server in your environment(s)?

For the Integrator

Are you still using LAPI to develop integrations?
If so, what is preventing you from using the newer CWS or REST APIs for your integrations?
Have you migrated an older LAPI application to a newer API?
Are there any common "gotchas" you would like to share with the community that you were able to overcome during the migration?

For those using the newer APIs, which API did you choose and how did you choose it?

Are there feature gaps between APIs that you are able to identify?

Thank you very much in advance,

Kyle Swidrovich
Product Manager | Research & Development
OpenText

Find more posts tagged with

Comments

Appu_Nair1

Kyle,

Just for my own info why isn’t ELS API (Enterprise Library Services) not being asked of. One seems to have used the ELS API to create objects in Livelink especially integrating SAP systems with Livelink

Is that a high level wrapper built with CWS underneath hence covered under that?

Best

Appu

From: eLink Entry: Content Server Development Forum [mailto:development@elinkkc.opentext.com]
Sent: Thursday, March 05, 2015 10:29 AM
To: eLink Recipient
Subject: [EXTERNAL]Use of LAPI vs. Content Web Services vs. REST API

Use of LAPI vs. Content Web Services vs. REST API

Posted bykswidrov@opentext.com (Swidrovich, Kyle) On 03/05/2015 11:25 AM

Hello all,

I'm looking to elicit feedback from the community regarding three external APIs into Content Server:

LAPI (Livelink API) -- available for many years, deprecated after 9.7.1
Content Web Services (CWS) -- first available in 9.7.1, continues to be available
REST API -- first available natively in CS 10.5 and optionally in CS 10

Your feedback will be used to help guide current and future development of our APIs for Content Server.
If you would rather respond to me privately, please feel free to do so via e-mail atkswidrov@opentext.com.

I have some specific questions depending on your role.
If you can provide some input here, indicating which role you best fit into, we would greatly appreciate it.

For the End User or Administrator

Finally, what are your current upgrade plans for Content Server in your environment(s)?

For the Integrator

Kyle Swidrovich
Product Manager | Research & Development
OpenText

[To post a comment, use the normal reply function]
Forum:	Content Server Development Forum
Content Server:	Knowledge Center

Kyle_Swidrovich

Hi Appu,

I’m focused on APIs that are natively provided with Content Server and the story around how those APIs are being used.

Other APIs, like the ELS API, may extend functionality beyond the core offering and provide added value.

Cheers,

Kyle

Fred_Bowen

Hi Kyle,

Funny you should ask.

A client of mine operates and maintains several application integrations developed using LAPI over the past decade. These applications have become the business fabric within the agency after all these years. As the agency has upgraded their several 971 instances to CS10 over the past 1-2 years, and now working toward CS10.5, the LAPI integrations have continued to work fine. But everyone I know is concerned about CS10.5 and the apparent deprecation of LAPI.

One of these LAPI-based integrations, a battle worn ASP (not .NET) application is up for redevelopment this year in C# .NET. Part of my job is to determine which Content Server API will best support this application for the next ten years. This is proving to be difficult, and as your post indicates, OpenText itself seems to be on the fence.

As a senior polyglot developer, I definitely have no particular love for LAPI, but in the spectrum of enterprisey APIs, LAPI has always been stable and performant enough to implement serious enterprise integrations that do not require much maintenance. A distinct disadvantage of LAPI, and CWS, is that these APIs require developers who have experience, or the resources to get deep experience, with a very niche API. That niche expertise is great personally, though little used for what it’s worth, but it drives up development costs for otherwise simple integrations for my clients. They cannot "just hire" any junior .NET developer to do maintenance on an aging LAPI app. That’s why these days I much prefer standards-based REST APIs over SSL that do not require niche knowledge about Content Server, LLValues, OScript, etc.

That said, it remains entirely unclear to me which path is preferred by OpenText for work I will begin for my client in the next 30 days. What are the pros/cons of LAPI, CWS, REST-API, ELS? Which one will be supported in 5-10 years? What is the compatibility and roadmap for these APIs in CS10, CS10.5, CS11. None of this information is readily available to me.

Any insight or reference material you can point me toward would be appreciated.

Thank you,

Fred Bowen

Managing Consultant, Application Development

Entium Technology Partners, LLC

http://entium.com

eLink User

Hi Fred,

I gave Kyle a similar interpretation but one thing I am not sure and differ is

You wouldn't hire a person who did not know the business rules of SAP to program something in ABAP?

So why use a different yard stick when it comes to livelink?

Why wouldn't organizations start to use livelink to its true potential it is not peanuts they spend to get it installed and running correctly?

What OT lacks in their training material is how people use livelink in a organization.A case in point.The new metadata example shows

a category getting created,then it is getting used to upload a document using that metadata?A lapi sample to create a category was also there perhaps the material was developed to mimic the replacement.

How many organizations would allow a lapi/cws developer to create categories in their livelink?

Wouldn't the sample be more like if you "had created a category using the gui or a program,you would use that template to attach metadata into livelink"

If a developer mistakenly interprets and creates a bulk loader program and creates a category for each object he/she uploads,would that livelink's search regions ever show?

Good clean samples that address what people use livelink in a organisation with an emphasis on

Real world scenarios DM (Document Upload,download,attach metadata,change metadata those kinds with a clean explanation on how the work could be checked using the browser)
Real world scenarios WF(Start a workflow,parse wf attributes,forms,attachments)
Real world search scenarios(search FT & category based) I would say this is well addressed in search xml api documenation. All users really get stuck on authentication.
How to use simple IIS SSO as most of the livelink's I have worked on were IWA based.

Until such time as OT gives "black box","junior" developers a OT sandbox to test code they develop they are up against many livelinks designed with business rules that suit them.If the black box was available then these young well meaning developers would know that the API's are very easily understandable and wouldn't bad mouth the product.

I did not write this as a criticism to OT but do put in at least 10 % more effort to support API developers timely .What amazes me in contrast is the WR forum every post has been answered there timely .Is there a concerted effort to push that as a dev tool?

..Appu

I wonder how one could debug livelink if Fiddler, Wireshark and Softerra LDAP browser was not invented and not free

On Fri, Mar 20, 2015 at 9:17 AM, eLink Entry: Content Server Development Forum <development@elinkkc.opentext.com> wrote:

RE RE Use of LAPI vs. Content Web Services vs. REST API Posted byfbowen@entium.com (Bowen, Fred)On 03/20/2015 10:08 AM

Hi Kyle,Funny you should ask.A client of mine operates and maintains several application integrations developed using LAPI over the past decade. These applications have become the business fabric within the agency after all these years. As the agency has upgraded their several 971 instances to CS10 over the past 1-2 years, and now working toward CS10.5, the LAPI integrations have continued to work fine. But everyone I know is concerned about CS10.5 and the apparent deprecation of LAPI.One of these LAPI-based integrations, a battle worn ASP (not .NET) application is up for redevelopment this year in C# .NET. Part of my job is to determine which Content Server API will best support this application for the next ten years. This is proving to be difficult, and as your post indicates, OpenText itself seems to be on the fence.As a senior polyglot developer, I definitely have no particular love for LAPI, but in the spectrum of enterprisey APIs, LAPI has always been stable and performant enough to implement serious enterprise integrations that do not require much maintenance. A distinct disadvantage of LAPI, and CWS, is that these APIs require developers who have experience, or the resources to get deep experience, with a very niche API. That niche expertise is great personally, though little used for what it’s worth, but it drives up development costs for otherwise simple integrations for my clients. They cannot "just hire" any junior .NET developer to do maintenance on an aging LAPI app. That’s why these days I much prefer standards-based REST APIs over SSL that do not require niche knowledge about Content Server, LLValues, OScript, etc.That said, it remains entirely unclear to me which path is preferred by OpenText for work I will begin for my client in the next 30 days. What are the pros/cons of LAPI, CWS, REST-API, ELS? Which one will be supported in 5-10 years? What is the compatibility and roadmap for these APIs in CS10, CS10.5, CS11. None of this information is readily available to me.Any insight or reference material you can point me toward would be appreciated.Thank you,FBFred Bowen
Managing Consultant, Application Development
Entium Technology Partners, LLC
http://entium.com
[To post a comment, use the normal reply function]
Topic: Use of LAPI vs. Content Web Services vs. REST API
Forum: Content Server Development Forum
Content Server: Knowledge Center

Kyle_Swidrovich

Hello all,

We offer a number of APIs within the world of Content Server:

<![if !supportLists]>1) <![endif]>REST API

<![if !supportLists]>· <![endif]>Our most recent Content Server API; uses HTTP and REST principles

<![if !supportLists]>· <![endif]>Seeing the most active development within OpenText to support UI Widgets and future UI enhancements

<![if !supportLists]>2) <![endif]>AppWorks

<![if !supportLists]>· <![endif]>A development framework that can aid in rapid mobile app development among other types of HTML5 applications

<![if !supportLists]>· <![endif]>Not specific to Content Server

<![if !supportLists]>· <![endif]>Acts as a frontend for a variety of OpenText REST APIs from various OpenText applications (e.g., Media Manager, Content Server, Cordys, etc.)

<![if !supportLists]>3) <![endif]>Content Web Services

<![if !supportLists]>· <![endif]>Released as a component of Livelink 9.7.1 as “Enterprise Web Services”; a service-oriented API

<![if !supportLists]>· <![endif]>Uses SOAP (XML) over HTTP for communication between client + server

<![if !supportLists]>· <![endif]>Has been the API of choice for many integrations, both internally at OpenText and externally

<![if !supportLists]>4) <![endif]>Content Server Internal APIs

<![if !supportLists]>· <![endif]>This is the framework that lets developers customize Content Server through the use of Builder / CSIDE

<![if !supportLists]>· <![endif]>Common concepts here are LLNode, WebNode, CSNode, PrgSession, etc.

<![if !supportLists]>· <![endif]>CSNode is our latest addition to this family and development against CSNodes can help with rapid development and shielding the customization from the effects of patching/upgrades

<![if !supportLists]>5) <![endif]>Oscript API

<![if !supportLists]>· <![endif]>This is the lowest level you can get within Content Server

<![if !supportLists]>· <![endif]>This encompasses the DAPI, CAPI, UAPI and WAPI family of APIs

<![if !supportLists]>· <![endif]>Content Server itself is an application built using the Oscript language

<![if !supportLists]>6) <![endif]>Search (XML) API

<![if !supportLists]>· <![endif]>The “?func=search” API used by Content Server itself to deliver search functionality

<![if !supportLists]>· <![endif]>Also available for customers/partners to implement search solutions against, and is the simplest interface for performing searches

<![if !supportLists]>· <![endif]>Can provide output in a variety of formats (HTML, XML, Atom or RSS)

<![if !supportLists]>7) <![endif]>Content Intelligence API

<![if !supportLists]>· <![endif]>a.k.a., WebReports + ActiveView and friends

<![if !supportLists]>· <![endif]>WebReports -- Allows users to create applications with Content Server through the use of replacement tags, through the UI of Content Server itself

<![if !supportLists]>· <![endif]>ActiveView – Allows users to change the look and feel of standard Content Server, providing a dynamic UI depending on who, how, when, and where the information is being accessed

<![if !supportLists]>8) <![endif]>LAPI (Livelink API)

<![if !supportLists]>· <![endif]>The longest standing external API for Content Server (Livelink)

<![if !supportLists]>· <![endif]>LAPI development ceased after 9.7.1

With the release of Content Server 10 in September 2010 (4.5 years ago), we indicated the following in the release notes:

LAPI is deprecated in Content Server 10.0.0. This means that this API should be avoided

because it may be removed completely in future versions of Content Server. Content Server

9.7.1 introduced the SOAP-based Web Services that cover the same functionality of LAPI. Future

Content Server integrations should be implemented using these Web Services. Legacy

integrations should be refactored to use the Web Services before moving to a future version of

Content Server.

As such, as a part of the upgrade plans to CS 10 or CS 10.5, migrating LAPI applications to a newer API should be (or should have been) considered by organizations with LAPI applications in their environment.

My effort to reach out to the community regarding LAPI is to better understand who is still using LAPI and why migration efforts haven’t happened yet.

I can’t necessarily speak to which API is best for a given deployment.

As you noted, it really depends on a variety of things:

<![if !supportLists]>1) <![endif]>Does the API in question provide the functionality you need for the actions you wish to perform against Content Server?

<![if !supportLists]>2) <![endif]>What protocols and deployment models work best within your ecosystem?

<![if !supportLists]>3) <![endif]>Do you have people within your organization that can code comfortably against the API you’re considering?

<![if !supportLists]>4) <![endif]>How important is the ease of upgrading to you?

As to how long these APIs will survive for, with the exception of LAPI, the APIs I’ve noted on this list still have a long life ahead of them.

My role in the Product organization is specifically around Content Web Services, so I can only really speak to its particular future.

Our next major version of Content Server will definitely support the APIs I’ve noted above, with the exception of LAPI.

We have a 5 year support lifecycle for major versions of Content Server now, so support for these APIs will live for at least 5 years.

Given my position at OpenText, I’m mostly interested in hearing pain points around CWS.

If there’s something you used to be able to accomplish using LAPI that is not available in another Content Server API, please let us know.

The sooner we hear about it, the sooner we can try to fill that gap for you.

If you have any comments regarding APIs other than Content Web Services, I can definitely pass any and all feedback to the appropriate Product Managers.

OpenText is currently working on clarifying the message to customers regarding options for development in the Content Suite and when to use what.

This will take some time, but we do hear you, we do understand that there is confusion out there, and we’re looking at coming up with a clear strategy for customers and partners.

Cheers,

Kyle Swidrovich
Product Manager | Research & Development

Fred_Bowen

Hi Kyle,

The biggest obstacle to migrating away from LAPI is the not-insignificant cost of redeveloping a core piece of otherwise functional applications. Realize the budget to upgrade ContentServer often comes from a different cost center than the applicants that integrate with it. For all of my clients invested in OpenText, the ContentServer budget comes from IT whereas the applications that integrate with ContentServer are funded by smaller departmental budgets.

Another problem is the proliferation of newer APIs, the steep on-ramp to begin using them, and the derth of information about choosing one and moving to it. Your reponse above is the best single source of information about my options that I've yet encountered. Consider the CWS knowledge center page which says:

All web services are defined in OScript. Java, C# and web service APIs are generated for the client. The web service APIs can be deployed on IIS using ASP.NET (WCF) or on a Java application server

The CWS page make it seem like leveraging a SOAP/XML webservice might involve writing the "server" portion in OScript. All I want is a to be a "client" of a webservice that completely replaces LAPI with all the same features and performance.

Then consider: I have had a thread going in circles with OT support today simply to determine whether CWS10 and CWS10.5 were API-compatible. That is, I need official documentation from OT that indicates whether an intergration developed against CWS10 will continue operating when the platform is upgraded to CWS10.5. Does that simple question have an easy answer? Meanwhile, LAPI971 has remained compatible from LL9.5 to CS10 without changing a single line of code.

Thanks,

Fred Bowen

Managing Consultant, Application Development

Entium Technology Partners, LLC

http://entium.com

Kyle_Swidrovich

Thank you Fred for your insight.

I’ve definitely taken your comments to heart and will continue to work on improving the messaging around web services, along with recommendations and guidelines around migrating away from LAPI.

With regards to CWS 10 & CWS 10.5 API compatibility, I think you’re probably fine, but a more definitive answer would come from the guys that develop these components. If you have a ticket number, I can connect support with the right people to get you an answer.

Thanks again and all the best,

Kyle

Kyle_Swidrovich

Hello all,

I was just informed of a whitepaper we published in the Champion Toolkit in December 2014 that touches on the various API offerings.

Please feel free to give it a read:

https://knowledge.opentext.com/knowledge/cs.dll/Properties/56860905

Cheers,

Kyle

Yu_Kevin

hi Kyle,

I am currently converting LAPI code to CWS. now my question might a bit off your topic but I wonder if there are any guide on how to convert LAPI code to CWS. Specifically on the API mapping since LAPI is deprecated.

Thanks

Kevin

Kyle_Swidrovich

Hi Kevin,

We’re currently working on developing that exact document.

An older document exists in the Champion Toolkit, although it does not have full coverage for all available web services:

https://knowledge.opentext.com/knowledge/cs.dll/Overview/KBA750007

It may be a good starting point.

Cheers,

Kyle

Yu_Kevin

hi Kyle,

Thanks for the link.

What was in OT's mind when announcing the deprecation of LAPI?

The customers are now trying to move away from LAPI but then there is no proper support yet for migration to the CWS.

That doc was last updated back in 2008. it took over 7 yrs to realize that something like that should be done in the first place?

Kevin

Kris Boutilier

If that document could be extended to encompass the REST interfaces too then it would add considerable value.

Granted the REST API will probably always be neccessarially less fully featured than SOAP/CWS, but it would be very helpful to have a single master reference over all methods available to access and manipulate a given piece of data.

Kyle_Swidrovich

@Kevin: I unfortunately can't speak for what has happened in the past as I took on product management of Content Web Services early this year. I can only say that this year we are putting a considerable effort towards supporting the LAPI migration activities of our partners and customers.

@Kris: I believe the REST API capability is also being evaluated as a part of this effort.

Yu_Kevin

@Kyle, please don't take me wrong, I understand that it's never the tech's decision for this kind of situation. obviously you are doing the right thing here by listening to the customers need.

I feel that the pay to play business model is a bit extrame for OT. there are options out there that are more open and have better support. in some case, customers will choose to move on to other solutions. then again, I hope you could reflect this kind of voice to the business.

yaronlu

Hi,

Is there a way to make the rest api work on cs10 sp2 update 10?

In the release notes it is mentioned that the rest api is available since update 13.

I wonder if there is a patch bundle I can add to cs10 update 10 , in order to make

it work (for a client which does not seem to upgrade in the nearest future)

Thanks and appologize for being a bit off topic.

Hans Stoop

The patch bundle you need to install is update13. Updates are just patch bundles.

Hans

From: eLink Entry: Content Server Development Forum [mailto:development@elinkkc.opentext.com]
Sent: Mittwoch, 9. September 2015 11:21
To: eLink Recipient
Subject: RE Re RE RE Use of LAPI vs. Content Web Services vs. REST API

RE Re RE RE Use of LAPI vs. Content Web Services vs. REST API

Posted byyaron_lu@malam.com (m, y) On 09/09/2015 05:19 AM

Hi,

Is there a way to make the rest api work on cs10 sp2 update 10?

In the release notes it is mentioned that the rest api is available since update 13.

I wonder if there is a patch bundle I can add to cs10 update 10 , in order to make

it work (for a client which does not seem to upgrade in the nearest future)

Thanks and appologize for being a bit off topic.

[To post a comment, use the normal reply function]
Topic:	Use of LAPI vs. Content Web Services vs. REST API
Forum:	Content Server Development Forum
Content Server:	Knowledge Center

Alex_Kowalenko

Kyle, Are my statements correct?

LAPI works on CS 10.0 and 10.5.

"LAPI is deprecated in Content Server 10.0.0. This means that this API should be avoided because it may be removed completely in future versions of Content Server."

LAPI will not work on CS 16.

"Our next major version of Content Server will definitely support the APIs I’ve noted above, with the exception of LAPI."

-alex-

Kyle_Swidrovich

Hi Alex,

That is correct.
Use of LAPI against CS 16 is no longer possible.
Any LAPI applications will need to be rewritten to work with one of the other APIs.

We're working on a document to help map LAPI functions to functions in CWS or the REST API (if available).

Cheers,
Kyle

Alex_Kowalenko

Thank you Kyle! Here is a fancy diagram showing LAPI's status,

Philip_Robinson

Hi all,

Is there an update to this document now available? Would be very useful.

Otherwise is there an up-to-date document stating best-practices or guidelines/ experience for using the REST API for document upload?

Thanks,

Philip

Kyle_Swidrovich

Hi Philip,

The document is still in progress.
You may want to head over to the forums at developer.opentext.com for specific assistance / examples around the REST API.
This post, in particular, is likely of value to you:

https://developer.opentext.com/webaccess/#url=/awd/forums/questions/8811/create+document+via+rest

Cheers,
Kyle

Philip_Robinson

Thanks Kyle,

Very useful indeed. Thanks for sharing that.

Best regards,

Philip

Tom Lunding

Hello Kyle,

I've been searching the knowledge center to find some information about the Rest API. What is it, how to use it, and some guides to make a real world example. I did not find anything. That is proberly the reason we only focus on the Web Service and Search API.

So my first question to you. Where to find the Rest API workspace with all relevant information to get started?

Thank you.

Regards,

Tom

Kyle_Swidrovich

Hi Tom,

The REST API documentation is currently available at the AppWorks site,https://developer.opentext.com.

There is a quick start guide available here as an article:

https://developer.opentext.com/webaccess/#url=%2Fawd%2Fresources%2Farticles%2F6102%2Fcontent%2Bserver%2Brest%2Bapi%2B%2Bquick%2Bstart%2Bguide&tab=501

The article links to the Content Server REST API v1 technical docs, but we have a newer one available under Resources -> API Reference -> Content Server API v1 (2014-06).

The forums also have a lot of question/answer pairs around REST API usage, as well as various examples for certain use cases.

I think they’re looking to make the REST API documentation available on the KC, but I don’t know any details on that.

Regards,
Kyle

Alexey_Kanishchev

Hi Kyle!

We are running CS 10.0.2 and still using LAPI.

We are afraid that the story with gradual discontinuation of LAPI's functions and the final discontinuation of this technology repeats in CWS or REST API.

You mentioned that in 5 years the CWS and REST API will be supported. But do you mean that every function/class/method/construction and so on that is supported now will be supported in the next 5 years?
What will be supported in the next 10 years? I mean what API should we use in our custom-code now to be sure that the code will work after update 2027?

Where can I look for the CWS, REST API, ELS, ECMLink API (web services) 5 years roadmaps?

Kyle_Swidrovich

We strive to keep the interfaces as static as possible from update to update, and even from version to version.
Given that the Smart UI in Content Server 16.x relies on the REST API to function, most active development is with the REST API, securing its place for many years to come. Content Web Services is still supported but we rarely add enhancements to it.

I would recommend using the REST API in your project if the functionality is there to support your needs.
If the REST API comes close but it's missing one or two things, please contact Customer Support to voice your needs and we'll see what we can do about filling in the gaps.

Cheers,
Kyle

LorenP

Hi Kyle,

We have used LAPI to populate category attributes that are attached to documents, to populate workflow attributes, start workflows and retrieve workflow attribute values when they are completed. Do CWS or Rest APIs have this capability?

Kyle_Swidrovich

I believe the answer is yes, in all cases.

The Smart View in Content Server 16.x uses the same public REST APIs that we document in Swagger docs and publish on My Support.

So if you can do something in the Smart View, the REST APIs are very likely there publicly for your use.

Content Web Services should also provide this functionality. They’ve been around since Livelink 9.7.1 and hit the mark for feature sets for most consumers of the API.

Kyle

LorenP

I was looking for that document that maps LAPI classes/methods to CWS and Rest but I can't find it. Does anyone know where that might be?

LorenP

I tried this link "https://developer.opentext.com/webaccess/#url=/awd/forums/questions/8811/create+document+via+rest" but I get this error "Can’t reach this page". This document would be very helpful to me. Where did it go?