From an input OpenAPI definition, our approach extracts first an OpenAPI model which is then transformed into a UML model (i.e., Class diagram) showing the data structure and operation signatures of the API. We propose a model-based approach to visualize OpenAPI definitions as UML Class diagrams. Section 4 concludes the paper and presents the future work. Section 2 describes our approach and Section 3 presents the tool. The rest of the paper is organized as follows. Only JSONDiscoverer allows visualizing the data schema of JSON-based REST APIs but focus on the inputs/outputs of the operations and does not model the operations themselves nor supports OpenAPI descriptions. To the best of our knowledge, current documentation tools for OpenAPI (e.g., ReDoc and Swagger UI) display the operations and data structures of the definitions in HTML pages using only text and code samples, which complicate the understanding and visualization of REST APIs. In this paper we propose a tool, called OpenAPItoUML, which contributes to this ecosystem by allowing the visualization of OpenAPI definitions as UML Class diagrams (including both the structure and behavior of the API), thus offering a better visualization of the capabilities of REST APIs. There is therefore a need for creating an ecosystem of supporting tools to facilitate the integration, development, and documentation of REST APIs described by OpenAPI (e.g., generating client SDKs, documentation pages or server skeleton). For instance,, a repository of OpenAPI definitions, lists more than 800 APIs. OAI has succeeded in attracting major companies (e.g., Google, Microsoft or IBM) and has created the OpenAPI specification (initially based on Swagger), which has become the choice of reference to describe REST APIs. Recently, and aiming at standardizing the way to describe REST APIs, several vendors have announced the OpenAPI Initiative (OAI). The growing importance of REST APIs has been supported by the proposal of several languages aimed at formally describing REST APIs and therefore facilitating their discovery and integration (e.g., Swagger, API Blueprint, and RAML). For instance, reports from ProgrammableWeb, the biggest repository of public Web APIs with more than 19,000 APIs, show that more than 80% of the registered APIs are REST. Due to its lightweight nature, adaptability to the Web, and scaling capacity, REST has become the preferred style for building Web APIs. The REpresentational State Transfer (REST) is an architectural style which allows relying on URIs and HTTP messages to build interoperable Web applications. Come to see OpenAPItoUML live if you’re around or check the content of the paper below (you can also download the paper on PDF). This work is going to be presented at ICWE’18 (18th International Conference on Web Engineering). All the instructions on how to install and use the tool are available in the Github repository. OpenAPItoUML is available as an open source Eclipse plugin. In this post, we present a tool called OpenAPItoUML, which generates UML models from OpenAPI definitions, thus offering a better visualization of the data model and operations of REST APIs. However, current documentation tools for OpenAPI only describe REST APIs in HTML pages using text and code samples, thus requiring a considerable effort to visualize and understand what the APIs offer. OpenAPI specification has become the choice of reference for describing REST APIs, and its adopters can benefit from a plethora of tools for documenting, developing and integrating REST APIs. In particular, a consortium of companies has created the OpenAPI Initiative, which aims at creating a vendor-neutral, portable, standard and open specification for describing REST APIs. This increasing adoption has triggered the creation of languages to formally describe REST APIs, thus facilitating and promoting their usage. REpresentational State Transfer (REST) has become the prominent architectural style for designing Web APIs. (you can now read about WAPIml, the successor of the OpenAPI to UML, described here )
0 Comments
Leave a Reply. |