Comparing APIs - CWS vs AppWorks vs CS REST API 1.0

Harvey Flaisher

We are about to create a new web app which needs access both to CS 10 workflow/documents and an external db. From what I can tell, there are 5 web svc APIs:

1. CWS
2. CS Rest 1.0
3. AppWorks

I have read https://developer.opentext.com/webaccess/#url=/awd/forums/questions/1130441#r1130448m but
what would really be useful would be a grid showing cs10/cs10.5 for CWS calls, REST API 1.0 calls and AppWorks calls (6 columns) and then having rows showing features, then putting checkmarks in the grid. I want to use REST (AppWorks?) since they are presumably simpler than CWS, but I am completely confused by which of these 3 products does what. We need to have CRUD capabilities for workflow and attached docs. Will any/all of the above do this?

could someone please point me in a direction?

thank you

jdonpaul

Hi Harvey,

Currently, the REST API functionality for Workflow has not been implemented. Your best option if you want to implment CRUD capabilities is to use CS Web Services or to wait for the REST API functionality for Workflow to be implemented.

I can understand the confusion between the two. So in order to de-mystify and seperate usage of REST API and Web services, here are a few thoughts on on how to approach CS development.

Server-to-server applications (e.g., a bulk operation) would be written using Content Web Services.
Client-to-server applications (e.g., a mobile client, desktop app) would be written using REST API.

In essence, these thoughts summerizes the webpage that you were referencing. I hope these thoughts point you in the proper direction.

HFCDev

Just to add to this answer, the REST API that ships with CS 10U11+ and CS 10.5 should be used within your corporate firewall, and AppWorks is a wrapper for the REST API that you'd use if you wanted to expose your web client to the outside world.

As for Workflow extensions, I know that it is on the product road-map meaning you'll get it out of box at a later date. I did go ahead and write my own Workflow REST extension this summer just to see if it could be done, so I know this is doable.

-Hugh

Ferdinand Prantl

Tough decision, if you want to deliver the solution today and not wait for OpenText to provide the REST API, which may take a couple of months.

Using the SOAP WS in the web browser is clumsy; the requests and responses were meant for machine processing; not for manual composition an decomposition in JavaScript. You could try integrating some third-paty library to help with it. However, this is not the intended usage scenario of the SOAP WS. New feaures web browser applications will be added to the REST API and you will be pushed to switch to the REST API later, at least when the Workflow resources are added there.

To be able to use the REST API in the browser, you would need to deploy your own resources for Workflow operations to the CS, because the CS provides you only with the general node access. You would need an OScript developer for this. However, you would not need to implement a complete Workflow API in general; your REST API extension would be the necessary minimum decided according to the needs of pages and actions that your application includes.

AppWorks exposed a REST API to access the CS from its applicationa earlier, but it did so because the CS itself had not done it yet. The current API development of the CS core and other modules provided by OpenText is based on the native CS REST API. You should not think about it as a CS REST API provider. As Hugh says, you can grab AppWorks, if you are looking for a reverse proxy for (not only) the CS REST API. Actually, AppWorks is an application server, first of all, but it'd be another topic about where to deploy your application.

You see that there is no optimal solution today. SOAP WS in the browser is more difficult (read expensive) to use and it is a dead end, although you can probably walk it for a long time. REST API means extra expenses for the API developer right now. Or buy Hugh's custom Workflow REST API :-)