Start a new topic
Planned

Direct RapidML -> OpenApi 3.0.x generation

The only way to generate OpenApi 3.0 from RapidML specs seems to be a two stage process of

  1. RapidMl -> Swagger 2.0
  2. Swagger 2.0 -> OpenApi 3.0
.

This unnecessary punishes users who take care to use non-legacy spec format.  Can you kindly consider adding direct OpenApi 3.0 generation.

Hi Ilja,


Thanks for the suggestion.  This one is on the roadmap!


In general, OpenAPI 3.0 support is the primary goal we are focused on now, including code generation, Normalizer and mock service. An OpenAPI v3 version of the RAPID-XChange GenTemplates will follow.


Ted Epstein |   |       skype:ted.epstein

Oh, that's awesome! Thank you.


I'd be nice to have a documentation describing difference between those two gentemplates. I presume that XChange is either the newest one or the one that is meant for automatic post-processing, but I have never seen any confirmation or documentation on that.

Right, it looks like "RAPID-XChange" is a brand name we pulled out of thin air.  


In fact it is a specification that formalizes a mapping from RAPID-ML, which is an abstract model of the API, to a concrete wire format that can be described in OpenAPI 2.0 or 3.0 using one of two modes: "Contract" (RXC) or "DTO" (RXDTO).  


The RAPID-XChange specification document is internal, pending finalization.


The RXC GenTemplate is complete, and is currently the only supported RAPID-ML --> OpenAPI conversion path.


The RXDTO GenTemplate is currently labeled as "RAPID-XChange Interop," and is not completely implemented. 


And the differences between RAPID-XChange Contract and RAPID-XChange DTO still need to be documented properly. 


I think you can expect all of this to be completed and clarified with the RAPID-XChange v3 GenTemplates.


Ted Epstein |   |       skype:ted.epstein


Login or Signup to post a comment