I've seen this question pop up a few times, but never a clear answer.
Is there some form of support for Swagger for a Progress REST-api? If not: will there be in a future version?
There are 2 types of descriptions at the moment:
WADL: We can export the wadl to apimatic and convert it to a swagger format. But the wadl-format is very basic, so you have to edit the swagger file manually.
JSON-Description: Unless I'm mistaken, it's not possible to use this with Swagger.
I don't think you can get away without Swagger support nowadays. If we mention "REST', the first thing the customer says is: 'where is the Swagger link?'
I don't understand why the json-description was chosen over something like Swagger.
Use cases for us:
-We have a team of openedge developers creating a REST-api for a team of angular developers. It would be nice if modifications to the api would be automatically reflected in Swagger as well.
- We also have an api that's used for third-party developers to create a link to our software. The first thing they ask is where the swagger-description is hosted.
- keeping an overview of the api
I should also mention, we also have a team of .Net developers. If they create a webApi, the swagger definition gets automatically generated as well. Not sure if its a Microsoft tool, but it exists (+ oauth support & easier setup). And it makes the .Net developers point & laugh at us :-)
I'm also interested in Swagger support.
At a simplistic level, could we build something that can parse a temp-table or prodataset definition and produce the swagger definition?
There is also a project to help in building code generators for different languages to support Swagger. But that is swagger to ABL.
I have written a sample tool that you could find useful for Swagger support:
Please notice that this is a sample and it is not a supported tool.
This sample program (genoas) generates an OpenAPI Specification file from a catalog file.
You get the catalog file from building OpenEdge Data Service used for Kendo UI Builder and Mobile support with the JSDO.
There are some few ways to enhance the utility further to support general REST/WEB transport in OpenEdge.
Perhaps, parsing the internal artifacts and generating the file or as a previous post suggested to parse temp-table and dataset definitions.
How do you approach the work with your API?
Would you write the API spec first then generate the REST service? (In this case, the code generation would be more important.)
If you have comments or suggestions on the tool, please post them to the document:
I saw your thread. Very interesting. I like the approach as well.
But you need a json catalog.Which is, yet, another format to describe a REST-api. We use a REST-project, not a mobile-project (or whatever is called these days (webapp??)).
You mention you could enhance the utility for general REST-transport. Would that be much work? Since the json description i get from the REST-api seems quite different from the json-catalog-description (cdo?)