Subject area

REST interface and rights

The HTTP routes under /crms, the roles CRMS decides with, the one error shape with keys, and the client an application uses to call a CRMS service of its own.

CRMS has an HTTP interface under /crms. Through it, applications render reports, a template editor works on templates, and authorized people read, verify and erase final documents.

The interface itself decides almost nothing. CIAS says who is asking. The CRMS modules decide what this person may do, based on their roles. Every error comes back in the same shape, with a key instead of a sentence.

The endpoints: all routes and who may call them
The roles: which role allows what and where CRMS gets it from
The error answer: the one shape, keys and status codes
The client for a separate service: crms-client, when CRMS does not run embedded

Topics in this subject area

1.The endpoints
All HTTP routes of CRMS under /crms: render, edit and approve templates, read and verify final documents. Where they run, what they accept and who may call them.
2.The roles
Which role allows what in CRMS: writing templates per scope, approval stages, reading, holding and erasing documents. How CRMS reads the roles from CIAS and where you set them.
3.The error answer
Every CRMS error has the same shape: messageKey, code, layer and, where needed, violations. Which key gets which status code and where all keys are listed.
4.The client for a separate service
crms-client talks to a separate CRMS service over HTTP: the same ports as embedded, the person's token is passed on, timeouts and errors come back as the same exceptions.