This is a Github issue submission I received, in response to whether or not anyone is doing anything interesting with Swagger. In the lead up to talks about Swagger next week at Gluecon, in Colorado. I'm pretty impressed with this work at UCSB, and while I am processing it, I wanted to share with you, and hopefully stimulate others to share what they are working on behind the scenes, using Swagger--I've gotten some pretty cool submissions so far.
We use Swagger in a series of on going research projects at the RACELab of UC Santa Barbara. Our research focuses on designing and implementing new mechanisms for governing APIs in cloud platforms. Following are some of our published works that make use of Swagger.
- Towards Automatically Estimating Porting Effort between Web Services APIs -- International Conference on Services Computing 2014
-
Using Syntactic and Semantic Similarity of Web APIs to Estimate Porting Effort -- International Journal of Services Computing, vol. 2, No. 4, Oct-Dec 2014
-
EAGER: Deployment-time API Governance for Modern PaaS Clouds -- IEEE International Conference on Cloud Engineering 2015, Future of PaaS Workshop
- REST Web Service Maintenance Through API Policy Enforcement -- UCSB Computer Science Tech Report
In first two papers, we use Swagger as a mechanism for describing the syntax and semantics of web APIs. The base Swagger standard covers all the crucial syntactic features of the APIs. We extended the base Swagger specification to include some simple axiomatic semantics (API preconditions and postconditions). We use this syntactic and semantic information to measure the similarity between different API alternatives.
In EAGER (Enforced API Governance Engine for REST), we use the base Swagger 1.1 standard to describe all APIs deployed into the cloud. We auto-generate Swagger descriptions from Java (JAXRS) source code at the compile-time using a custom Maven plug-in. Once uploaded to the cloud, we use Swagger descriptions to validate APIs, enforce policies on them and establish the backward compatibility between different versions of the same API. This way we can prevent or warn the API developer when a backward incompatible API change is being rolled out into a production cloud.
