REST service module for Mendix. Supports consuming and publishing REST based services and real-time data synchronization. Supports JSON, form-encoded, multipart and binary data transport.
I ran into an issue with the /rest/ documentation as generated by the module.
I have (example) the following services:
GET /tickets - Retrieves a list of tickets
POST /tickets - Creates a new ticket
GET /tickets/{Id} - Retrieves ticket {Id}
PUT /tickets/{Id} - Updates ticket {Id}
These work fine, but have the following descriptions in the /rest/ documentation:
/rest/tickets?about --> Retrieves a list of tickets
/rest/tickets?about --> Retrieves a list of tickets
/rest/tickets/{Id}?about --> Retrieves ticket {Id}
/rest/tickets/{Id}?about --> Retrieves ticket {Id}
It appears that the logic that generates the documentation is unable to differentiate between different methods on the URL and will simply use the description for the first one in the ASU flow (GET, in my case) for all methods on the same URL.
I tried changing the places of POST and GET in the ASU flow (POST now first). The result was indeed that the description of the POST showed up in both descriptions.
Not a gamebreaker, as the services themselves work fine, but it is rather inconvenient from a documentation perspective.
Would it be possible, when using the same URL for POST/GET or PUT/GET (not an uncommon practice, to my knowledge) to include both descriptions in the documentation for that URL?
I ran into an issue with the /rest/ documentation as generated by the module.
I have (example) the following services: GET /tickets - Retrieves a list of tickets POST /tickets - Creates a new ticket GET /tickets/{Id} - Retrieves ticket {Id} PUT /tickets/{Id} - Updates ticket {Id}
These work fine, but have the following descriptions in the /rest/ documentation: /rest/tickets?about --> Retrieves a list of tickets /rest/tickets?about --> Retrieves a list of tickets /rest/tickets/{Id}?about --> Retrieves ticket {Id} /rest/tickets/{Id}?about --> Retrieves ticket {Id}
It appears that the logic that generates the documentation is unable to differentiate between different methods on the URL and will simply use the description for the first one in the ASU flow (GET, in my case) for all methods on the same URL.
I tried changing the places of POST and GET in the ASU flow (POST now first). The result was indeed that the description of the POST showed up in both descriptions.
Not a gamebreaker, as the services themselves work fine, but it is rather inconvenient from a documentation perspective.
Would it be possible, when using the same URL for POST/GET or PUT/GET (not an uncommon practice, to my knowledge) to include both descriptions in the documentation for that URL?