SDL Trados Studio
SDL Trados GroupShare
SDL Trados Business Manager
SDL Trados Live
SDL Speech to Text
SDL Managed Translation - Enterprise
Translation Management Connectors
SDL LiveContent S1000D
SDL Contenta S1000D
SDL Tridion Docs
SDL Tridion Sites
SDL Content Assistant
SDL Machine Translation Cloud
SDL Machine Translation Connectors
SDL Machine Translation Edge
Tridion Docs Developers
SDL User Experience
Language Products - GCS Internal Community
SDL Community Internal Group
SDL Access Customer Portal
SDL Professional Services
SDL Training & Certification
Language Technology Partner Group
SDL Academic Partners
SDL Enterprise Technology Partners
ETUG (European Trados User Group) Public Information
Machine Translation User Group
Nordic SDL Tridion Docs User Group
SDL Tridion UK Meetup
SDL Tridion User Group New England
SDL Tridion West Coast User Group
SDL WorldServer User Group
Tridion Docs Europe & APAC User Group
Tridion User Group Benelux
Tridion User Group Ohio Valley
SDL MultiTerm Ideas
SDL Passolo Ideas
SDL Trados GroupShare Ideas
SDL Trados Studio Ideas
SDL Machine Translation Cloud Ideas
SDL Machine Translation Edge Ideas
SDL Language Cloud TMS Ideas
SDL Language Cloud Terminology Ideas
SDL Language Cloud Online Editor Ideas
SDL Managed Translation - Enterprise Ideas
SDL TMS Ideas
SDL WorldServer Ideas
SDL Tridion Docs Ideas
SDL Tridion Sites Ideas
SDL LiveContent S1000D Ideas
SDL Contenta S1000D
SDL XPP Ideas
Events & Webinars
To SDL Documentation
To SDL Support
What's New in SDL
Detecting language please wait for.......
A RESTful Web Services API was added to the product with XPP 9.3.
It is available, and is distributed for use with any new installation or upgrade as of the XPP 9.3 release.
Replace Web Services with a RESTful API that is URL addressable for XPP functionality.
Low-level "micro" services (toxsf, compose, print, citi, etc) supported by XPP, that can be built upon for more high level customized functionality.
Still working out some of the details, but I will try to answer some of your questions.
The suggestion about 'wait' for the long API calls is valid. This would be 'print', compose, and user command , but I will point out that it is inconsistent as far as the API is concerned. All calls are synchronous except...
Files will be sent/received as attachments. This is the only known way of delivering files that can be "streamed" and not eat up memory when the files get large. Any kind of HTTP client can deal with form-attachments and the file auto-magically gets placed onto the file system. It does also support "inline", so if you were in a browser application make XPP REST calls (via jquery or some other client), the file would be streamed directly to the web-browser.
To get the status, you do a http://...../processes/:taskid. It returns the output of the command or a "running" if it is still active. Good idea about the current output being the last line of "stdout". Could be useful and sort of mimic what happens in the background processor. Will have to think about that.
Files created by "print"; ie. psfmtdrv or divpdf will reside on the file system. You name it with arguments to the "print" and it must be retrieved with a 'getfile' after the task is completed. You dont want to be passing files as base64 encodings in JSON returns because of memory usage (as stated above).
All good questions, and glad there is interest. REST is much better than SOAP