A Bunch of UX APIs

What Were They?

The naming proved challenging—"New generation APIs," "Version 2 APIs," "WebAPIs," and "UX APIs" were all considered. The concept involved having UX/perceptive applications built on TRIRIGA make REST calls configured through UX Designer components. These components enabled querying, creating, modifying, and deleting records, plus calling state transitions and workflows.

When opening the workplace services perceptive app, multiple calls occur for current user information and location details. The new implementation made these calls without a front end, "stitching together" multiple requests using React code to create functioning features. This approach served as "an alternate to the OSLC approach for integrations" motivated by performance and documentation considerations.

Performance

The author conducted extensive analysis comparing "OSLC vs UX APIs vs servlets for integrations." OSLC requests involved hundreds of validations, consuming transaction time. UX APIs bypassed this, though necessary checks required manual workflow configuration. This increased development effort but reduced transaction costs by optimizing which validations were actually needed.

Documentation

APIs needed building to match specific functionality. Room booking, for instance, required checking availability, verifying access permissions, holding rooms to prevent concurrent bookings, and finalizing reservations. These were split into microservices due to TRIRIGA limitations, then combined using an API Manager like IBM API Connect. This allowed exposing functionality as simple "POST /reserve" endpoints following OpenAPI standards.

The Reserve API consolidated 25+ individual APIs on TRIRIGA into 5 fully serving features. Final implementations covered Service Requests, Worktasks, Assets, Location Portfolio, HR Portfolio, and standard services for kiosks and mobile devices.