Code Generation of OpenAPI (fka Swagger) Still the Prevailing Approach
ICYMI: Over 50% of the projects I consult on still generate OpenAPI (fka Swagger) from code, rather than the other way around. When I first begin working with any API development group as an advisor, strategist, or governance architect I always ask, “are you using OpenAPI?” Luckily the answer is almost always yes. The challenge is that most of the time they don’t understand the full scope of how to use OpenAPI, and are still opting for the more costly approach–writing code, then generating OpenAPI from annotations. It has been over five years since Jakub Nesetril of Apiary first decoupled this way of doing API design first, but, clearly, we still have a significant amount of work when it comes to API definition and design literacy amongst development groups.
When you study where API services and tooling are headed it is clear that API deployment and the actual writing of code is getting pushed further down in the life cycle. Services like Stoplight.io and Postman are focusing on enabling a design, mock, document, test, and iterate approach, with API definitions (OpenAPI, Postman, etc.) at the core. The actual deployment of an API, either using open source frameworks, API gateways, or another method, is coming into the picture more downstream. Progressive API teams are hammering out exactly the API they need to without ever writing any code, making sure the API design is dialed in before the more expensive, and often permanent code gets written and sent to production. https://goo.gl/LaUAdg #DataIntegration #ML
Towards Resource-Oriented REST Development
In many areas, we see the use of shared conventions to foster productivity. Docker resp. OCI images start to take over the delivery and installation of server software. Kubernetes seems to be achieving the same for the orchestration of software. Graph databases are leading the way when it comes to modeling and evolving complex, interrelated data sets. In stark contrast, REST development seems to be heading in the opposite direction. Instead of relying on shared conventions, people specify their personal flavor with OpenApi. Developers have to fiddle with path mappings and status codes; maybe with one or the other library offering some short-cuts for common patterns. In contrast, highly efficient, asynchronous frameworks get built that scale to thousands of concurrent requests that only a few of us actually need. This article outlines a number of different possibilities to address these issues, move Java REST development to a higher level, and gain more productivity, consistency, and simplicity.
Ideas to achieve such goals are well established. For example, the Richardson Maturity Model specifies four levels of maturity for REST services. Services are supposed to make use of HTTP, have a resource-oriented architecture, perform proper mapping to URLs, and introduce links to facilitate the discovery of the API. Ideally, REST libraries would come with native support for such patterns. Such libraries may make use of three main building blocks in one way or the other: https://goo.gl/4vDMCt #DataIntegration #ML
