Change mapping of an consumed REST service

0
Hi,I am working in parallel with the Mendix app development on a backend function, which is integrated into the app via a REST API. Initially I used the consumed REST service within Mendix and imported the OpenAPI description of the backend. It's a fairly easy and fast way, but if there are changes in the data model of the REST API, it's quite complicated to implement these changes. I haven't found a way to change the JSON mapping in the consumed REST service function. I found a solution that works, but it's very inconvenient. I have to delete the existing entities from the domain model and recreate each entity with the new attributes.I am using Mendix Studio Pro 11.8.Is there a more convenient way to integrate data model changes within a REST service?The alternative, in my opinion, is to create a JSON file and an import/export mapping and use the Call REST service activity, but it will take much longer to integrate REST APIs with a large number of REST API endpoints.Thanks and regards,Ingo
asked
1 answers
0

Unfortunately, this is a known limitation of consumed REST services based on OpenAPI in Mendix. There is no convenient way to update the generated JSON mapping incrementally, so re-importing often leads to recreating entities.


If you want more flexibility without fully switching to manual mappings, you can consider using a Message Definition.


With a Message Definition, you define the JSON structure separately and use it in your import/export mappings. This gives you more control compared to the auto-generated structures from consumed REST services.


When the API changes, you can update the Message Definition and adjust the mapping without needing to recreate your entire domain model. This makes it more maintainable, especially for APIs that change frequently.


Alternatively, for full control, you can still use:

  • Call REST activity
  • Import Mapping (based on Message Definition)


So a practical approach is:

Use Message Definitions to decouple your JSON structure, and avoid relying fully on the generated artifacts from the consumed REST service.


If this resolves your question, please mark it as accepted.


answered