Streamline API Management
•Download as PPTX, PDF•
0 likes•264 views
Focus of Application-Developers creating business applications are on app-development and NOT how to manage APIs in the corporate API-Management platform. Hence plan your API-Management solution as a Self-Service platform with the goal to keep it simple for API-Providers as well. For instance by providing an integrated DevOps pipeline for their APIs in same way as for their software projects. This pipeline helps application developers to push changes of their APIs into the API-Platform frequently without any effort. And it must start at the design-phase until an API gets retired.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Streamline API Management
Similar to Streamline API Management (20)
More from Axway
More from Axway (20)
Recently uploaded
Recently uploaded (20)
Streamline API Management
- 1. Streamlining API & Microservice Workflow Zurich 2019 Christoph Wiechmann, Pre-Sales Consultant
- 3. axway.com API Teams in the Enterprise few years ago © 2019 Axway 3
- 4. axway.com APIs explosion in the Enterprise © 2019 Axway 4
- 5. axway.com The need for API Management Self-Service © 2019 Axway5
- 6. axway.comaxway.com API Management Self-Service: Two sides of the coin… API Consumer Self-Service API Provider Self-Service Enterprise-IT - Enabler of a Self-Service Platform API-Catalog, API-Discovery, API-Security & Governance © 2019 Axway 7
- 8. axway.comaxway.com DevOps your APIs … in the same way as your software. Design, Develop, Deploy …
- 9. axway.comaxway.com But why DevOps? It’s all about early feedback. Testable/Usable/Lovable https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp
- 10. axway.comaxway.com The API-Design diamond It must be a repeatable process 11The Design of Web APIs by Arnaud Lauret
- 11. © 2019 Axway Do you think this is hard?
- 12. axway.com
- 13. axway.com A process: Easy & repeatable – For Developers API-Design • {api:first} – Creating the API-First • Publish them into the API-Catalog API-Mock-Up • Get better feedback with API-Mock-Ups • Decouple API-Consuming- from API-Providing-Projects API-Creation / API-Implementation • Implement / Orchestrate an APIs in minutes API-Evolution • Perhaps adding new methods & parameters to an existing API And for Enterprise scale all this in Self-Service. So, what do we need? 14
- 14. © 2019 Axway Let’s do it.
- 15. axway.comaxway.com API-Design becomes possible for everyone. Create • Visual API & JSON-Schema Editor, Versioning, … Validate • API-Design Rule creation Mock • Swagger-API-Defintion creates the fundament Documentation • Platform for collaboration GIT-Based • Can be integrated into CI/CD-Pipeline {api:first} – Design an API Using Stoplight 16
- 16. axway.comaxway.com That‘s all we need: A Swagger-File + API-Config Swagger based API-Promotion 17
- 17. axway.comaxway.com Just the design Seamless integration between API-Design & API-Runtime • Must be easy, Repeatable & Self-Service • Ad-Hoc or CI/CD-Based Deploy • Deploy it to the API-Management platform • Get feedback on your design • Improve it and repeat At this point: No Mock, No Implementation – Just the design {api:first} – Design, Deploy … repeat 18
- 18. axway.comaxway.com {api:first} – Design an API and immediately deploy it Using Stoplight 19
- 19. axway.comaxway.com Getting better feedback with mocks {api:first} – Mock the API Using API-Builder 20 Axway API-Builder • Node.js based architecture • API-Builder project becomes a Microservice • Running as a Docker-Container • Supports API-First approach Create a Mock-Service • Import API (Swagger) • Save & Create Mocks Link designed API with API-Builder container
- 20. axway.comaxway.com Making the customer(s) happy. {api:first} – Implement/Orchestrate the API Using API-Builder 21 Axway API-Builder • Connectorless • but able to connect to any REST-API • Model-Driven • Extensible – e.g. create your own nodes/functions Implementing a flow • Create Connectors based on Swagger-Definitions • Create / Implement a flow Link the API to the API-Builder Microservice
- 21. Externalized API as Code Created an API definition by a Non-Technical person Complete Self-Service process • Using the “normal” development tools • Haven’t touched the API-Manager at all Not only the Vanilla-Case • Swagger-Promote supports all aspects of an API • Security, Tags, Custom-Properties, Custom-Policies, … • incl. Staging-Concept Changes to a „Published“ API - possible & simple • Integration-Tests avoid NO Breaking changes Summary 22
- 22. axway.com
- 23. axway.comaxway.com Stoplight Axway Partner Get in touch - visit Stoplight here at the Imagine-Booth Upcoming integration using Swagger- Promote Subscription based pricing Axway API-Builder Swagger-Promote CLI to enable DevOps your APIs Downloadable from the Axway Marketplace It‘s free and Open Source Official accelerator from Axway Tools being used 25 Supports a Microservice-Architecture Low-Code / No-Code It‘s free – Community-Edition Subscription based pricing for Enterprise-Support
- 24. Thank you! 26
Editor's Notes
- Hello everbody, welcome to the Axway Imagine here in Chantilly. My name is Christoph Wiechmann and I work at Axway as a pre-sales consultant in API-Management space helping customers on their digital journey. I’m really glad to be here and talk in the next 55-60 minutes about how to streamline the API-Development/API-Lifecycle workflow. Don’t be worried, besides slide-ware at beginning you will see some amazing stuff and together with you in this session I will create as a showcase an API from the beginning to the end.
- Before we step into that, I would like to illustrate what has changed in the API-Economy?
- API Teams used to be – a little bit like these guys - a very small team, very well trained, delivering a few APIs usually pretty fast
- Now APIs in the Enterprise today looks a bit more like that: adoption is becoming mainstream, many developers a building APIs, many business teams have needs, Product API Manager start to appear for more mature Enterprises…
- They need self-service
- And one the reasons for that, is the explosion of API on consumer and provider side.
- An API-Management-Platform needs Self-Service capabilities not only for consumers, which is around & established since a while, by offering an API-Catalog & Self-Service-Capabilities in an API-Developer portal. With that application-developers, API-Consumers can discover and subscribe to existing APIs. But you can only discover & re-use APIs already in the catalog. Therefore to get the most value out of the API-Management platform, also API-Service providers must have a easy way to integrate their APIs into platform. It must be seamless for them, as they normally have to focus on their business project and not how to integrate their APIs into the platform. However, API-Service-Providers expect, when adding their APIs into the platform, security to be applied without knowing the exact details and by that they get visibility & governance capabilities about their APIs and consumers. Some of our customers are using the API-Management platform for an API-Centric architecture. That means, all communication will go through the API-Platform, no matter if internal Application-2-Application or Cloud-2-Ground, Ground-2-Cloud communication. The ultimate goal is to improve Re-Usability & Speed as every business-project can now discover and leverage already existing APIs, for instance to use a Cloud-Service. But this requires that each new service developed in a business project, for instance by integrating a Cloud-Application, is integrated into the platform. Basically: By the way. And this will only work out, if integration is easy & seamless.
- So, it comes downs to a proper control the API-Lifecycle and automated everything using a DevOps process. Of course, self-Service enabled.
- I mean, all of you have seen this Infinte-Loop before, also in combination with API-Management. But it’s pretty hard to implement this … having a repeatable process, which is easy enough to really repeat it over and over again.
- But why is DevOps/Agile so important, also for APIs? Especially for an API-First approach you can consider an API like a product you would like to finally offer to your customers. And of course you have agreed on doing this based on certain requirements and maybe specification. But geeting early feedback on your planned product is important to build the best product. And this is, what the picture is about. Just having an agile process in place and delivering your product early to your customer makes only sense, if your customer can really provide feedback to you based on the delivery. For that, you need something testable and useable and later becomes maybe loveable. The example illustrates, with early feedback it might even turn out, to deliver a final product better than imagined. In that case, the customer realized feeling the wind is great, hence he decided for a cabrio. So, it comes down to deliver early and the same for API.s
- Arnaud Laurent recently finished his book „The Design of Web APIs“ and he defined the „API Design-Diamond“. Each side of the diamond describes what is important for a good API-Design and I think he is right, saying for instance that an API should be goal oriented, useable, etc. But all of these aspects requires some kind of evolution. I mean, it wont be possible to do it right from the beginning for an API-Designer or API-Developer to develop the perfect API. You require feedback, from API-Consumers, like App-Developers, etc. And to get feedback, you need to deliver quickly and repeatable.
- Who of you is actually using the API-Manager and believes handling all this is easy? I mean, providing an API, get feedback, change something, over and over again?
- At least I can say, this is how I felt when I had to do this.
- So, that means, we need a repeatable process starting from the API-Design, easy way to create an API-Mock-Up and finally start implementing the API. And even in that stage, it must be possible to apply certain non-breaking changes. And of course, I would like to have a Self-Service-Process to keep up with the enterprise-level demands.
- Who of you is actually using the API-Manager and believes handling all this is easy? I mean, providing an API, get feedback, change something, over and over again?
- Following the API-First concept, let‘s start by creating a brand new API just by designing the purpose of it. Suppose I‘m, now a API-Product developer, clearly having the business view on it. I want to create business methods, adding parameters and description to it, but I‘m not a Swagger-Specilist. So, I need a graphical way or design oriented tool to do my job. For that I‘m using stoplight, which allows me to do that. Let‘s do that quickly in a very short demo.
- It‘s a small, but very powerful tool, which requires a Swagger-Definition, plus an API-Configuration file and deploys it into the API-Manager. The need for the Swagger is obvious, but the config file tells the API-Manager how to manage/expose that API. Actually our API isn‘t very nice, as we don‘t have any picture, tags, for Front-End-Security. Let‘s make a another re-deployment, but this time with an updated config-file. After re-deployment we re-load the API and realize the API has now an Image, is exposed using API-Key based security and has some tags. All this is configured into the JSON-Based configuration file. Even if I‘m doing this right now interactively the initial intention is to have this tool executed by a CI/CD-System and of course it has a staging concept.
- So, as I have now designed my intial draft version of my API, what next? I need to deploy it into the API-Management platform to get feedback from my consumers. Even if it‘s only the API-Design, it already has some value, as consumers can explore it, read the documentation, etc. and with that they can give me recommedations about missing methods, parameters, etc. Let‘s deploy my API now and discover it in the API-Portal. And perhaps my API becomes very important I‘m getting tons of feedback, I want to include all of them. And perhaps I have deploy into more than 20 times. Hence it must be super easy to do that, do a certain change and deploy it to the API-Management platform. Over and over again, as illustrated in the loop. Let‘s suppose we have received some feedback, we want include them into the API-Design, re-deploy it and –rediscover it. As you have seen the process is super-simple and seems like repeatable.
- To make it even more simpler it would be good just to initiate this process out of the Design-Tool and our partner Stoplight is working on this integratin. With that, an API-Product-Designer, can just kick-off the process I have started manually right out of the API-Designer. These are mock-screens and they told me, an initial version should be available at this Imagine. You find our partner Stoplight here, if you want have a chat with them.
- So, now suppose our API-Design has evolved enough and it‘s time to provide a better delivery to my API-Customers to get better feedback to get from 3 to 4. I want to introduce a simple Mock-Service to indicate what kind of responses the API will return. For that I‘m using today API-Builder, which is a Node.js based application, helping me during the development phase, which a Low-Code approach to do my job and finally turns into a Docker-Based Microservice. It provides support for an API-First approach by creating a new API based on the Swagger-Definition and for now, we just create a Mock-Service. Nothing special. However, for those of you, who are working with the API-Manager, they know it‘s tough to get the API-Re-Linked to a new Down-Stream-Application. I mean, we need to tell the API in API-Manager where our Mock-Service is. With Swagger-Promote it becomes again super simple, just by adding the right Backend-Base-Path.
- Lastly for today, I would like to start implementing my API and again I would like to use API-Builder for that. It sounds a bit funny, but we call API-Builder Connectorless, as it comes not with >150 connectors, but has the capability to connect to any kind of REST-API. It‘s very simple, just by adding the Swagger-Definitions into my API-Builder project, I automatically do get a Connector for it, which I can use in my flow. With that I can now enrich, implement and test my flow right in the API-Builder. So, and as my API-Lifecycle comes into the „Published“ state, I would like to finally publish my API, grant access to a number of organizations and maybe automatically create a subscription to some existing applications. Now, as the API is finally published, all changes to that API should be applied carefully to avoid breaking-changes, but as many of you know, it‘s required sometimes to add new features to keep the API-Version stable as long as possible. And even that, is now possible. Let me simulate an extension.
- Who of you is actually using the API-Manager and believes handling all this is easy? I mean, providing an API, get feedback, change something, over and over again?