Integrations, REST and Web Services
Integrations, REST and web services
Consuming an API in Mendix usually starts with a consumed REST service document, created from an OpenAPI/Swagger file or defined by hand, or with a Send REST request activity inside a microflow. Responses arrive as strings, or are translated through a JSON/XML structure with an import mapping; export mappings do the reverse, turning entities into a structure that is then serialized. Each element of the structure maps to an attribute or an association.
Publishing is the mirror image: a published REST service exposes microflows as operations with path, query and body parameters and its own authentication choice (none, basic, active Mendix session, or a custom microflow). Published web services (SOAP/WSDL) and OData services follow the same pattern, and message definitions plus mappings do the translation work.
Traps
- Not checking the HTTP status code. Mapping a 400 or 500 response body as if it were success is a common bug; verify 200–299 before importing.
- Forgetting that an import mapping on an empty or malformed body throws an error - wrap the call in error handling and return a meaningful message.
- Content type and headers: many APIs reject a request without Accept/Content-Type, and query parameters must be URL-encoded.
- Published REST operations run in the caller's context; active-session authentication means the caller must already be logged in.
Rule of thumb
Treat every external call as unreliable: set a timeout, check the status code, log the response body at debug level, and fail with a user-readable message instead of a raw stack trace.