In diesem Workshop werden wir zunächst zeigen, worauf bei gutem API-Design geachtet werden muss, was der API-First-Ansatz ist, wie er umgesetzt werden kann und wie eine gute Dokumentation erstellt werden kann, um dann Strategien zum Testen und zur Evolution von APIs vorzustellen. Im weiteren Verlauf steht die Interaktion mit dem Client in Form von z. B. Caching, Validation und Asynchronität im Vordergrund. Den Abschluss bilden Themen zum Betrieb von APIs wie Security und Logging/Monitoring.
When it comes to web APIs, RESTful often is the default choice. But what if you need more? What if you need near real-time, duplex communication between systems? What if the client needs a lot of flexibility when querying the API backend? What if you need the best performance you can get when talking to backend Microservices? In this workshop, Rainer Stropek covers three interesting technologies that go beyond traditional, hand-coded RESTful web APIs. Together with Rainer you will dive into WebSockets with SignalR, OData and gRPC. You will only see a few slides in this workshop. The majority of the time we will work through and write code samples in C# and .NET Core.
Approaching problems with a serverless first mindset means rethinking, re-architecting, and rethinking again. Let's build a model for thinking serverless and practice applying it. Serverless isn’t just FaaS, it isn’t just about the cloud. We'll put our concept of serverless architectures to the test with a mindset to match.
Damit ein Web-API erfolgreich ist, muss die Welt wissen, welche Funktionalität es bietet. Swagger aka OpenAPI ist ein Standard zur Beschreibung von Web-APIs, auf dem eine Vielzahl nützlicher Tools aufbaut. Egal ob hübsch formatierte Dokumentationswebseite, generierter Server- und Clientcode, Einbindung in Workflowlösungen wie Azure Logic App – wenn man sein Web-API mit OpenAPI beschrieben hat, bekommt man diese Dinge mehr oder weniger automatisch. In dieser Session stellt Rainer Stropek OpenAPI vor. Gemeinsam mit ihm spezifizieren Sie ein fiktives Web-API mit OpenAPI. Anhand des API-Beispiels lernen Sie wichtige Tools kennen, generieren Code, veröffentlichen die API-Beschreibung zur Verwendung in der Cloud und vieles mehr.
APIs, microservices, containers, agile teams. You might think of it as autonomous changes, both in reality all are manifestations of the same core ideas. Individually, they are useful. However, in harmony, they make a forceful lever for change. Doing things faster, better, cheaper, and with a lot more fun. That’s the new way of working.
You’ve already collected a lot of information on digital transformation, microservices, policies, open banking, and the essential role of APIs – today and previously. You might be confused how to fit it into your situation. How and where to start? Or what would your best next step be? In this talk, you’ll get inspired by a stepwise growth model derived from practice. You’ll be introduced to the core implementation patterns for safe, reliable, and scalable API-strategy. A strategy that allows you to embrace future changes. An architecture around open standards, using mature, open source components of WSO2.
API First development – should you practise it? Of course. In this lightning talk, I'll show you how OpenAPI can make your life easier in a serverless world:
Did you notice that I just gave you five advantages of using OpenAPI? It's only the beginning. And that's why you should practice API First development with OpenAPI.
APIs help abstract complexity and allow easy access to data – building innovative apps has never been easier. However, once your user base reaches a critical mass, this can quickly cause performance issues and a miserable user experience. In this session we’ll introduce a concept that is similar to push notifications on your smartphone, we’ll talk about use cases and show you how easy it is to turn existing REST API endpoints into event-driven APIs that save you bandwidth, management cost and, ultimately, allow you to build engaging real-time user interfaces that delight your customers.
As APIs continue to become a core focus of organizations, ensuring quality is a major factor at every stage, while also speeding up development. To embrace this reality, we must develop pragmatic approaches for closed-loop processes, outcome-oriented development, and effective change management techniques to deliver on the promise of APIs. Joe Joyce, Solution Engineer at SmartBear will discuss these modern issues and outline impactful approaches for you to resolve the daily challenges they present.
The platform economy is ubiquitous within many sectors and is easily identified by the big four Google, Amazon, Facebook and Apple. Having wild success and global adoption and leaving regulated sectors scrambling to catch up. In this talk, we will explore how a German fintech is changing the dynamics and disrupting the financial sector with a SaaS platform by rethinking how APIs can offer regulations as a service, focusing on PSD2 as a service and GDPR as a service.
APIs originally evolved from messaging systems emerging from the proliferation of distributed systems. Bypassing the normal payload of application interactions meant a much faster performance when distance was a factor.
Distributed systems are now the norm rather than the exception and performance standards are higher than ever. Ensuring fast, reliable API systems in today's competitive landscape requires the staple of the distributed system: caching. Come and see how caching API responses can increase your API performance and reduce infrastructural requirements.
If you’re feeling unsure about the security implications of exposing your own services and systems to the world, then let us tell you now: you’re not alone, and we’re here to help.
During this session Yaara Letz, Tyk Consulting Engineer, will explain how API management and identity management can work together to secure your API programme.In the first part, Yaara will demonstrate the different methods for microservices authentication and authorisation, and illustrate how an API gateway fits into this.
As well as seeing some sample architectures, you’ll hear the pros and cons of a variety of different auth methods.In the second part of the workshop, Yaara will explain why it’s good practice to use a separate Identity Provider (IdP) with your API Management. She’ll finish with walkthroughs of 2 ways to secure an api with Tyk by integrating with a 3rd party IdP that supports the OIDc standard
The programming language Go is growing in popularity. It promises microservices with a small footprint while still offering high developer productivity. This session is for developers who wonder whether they should consider Go for their next microservices project. Instead of showing slides, Rainer Stropek demonstrates the capabilities of Go by developing an end-to-end web API example. You will hear about the principles of the programming language, see router, data access etc. in action, learn how to package the web API into an efficient Docker container, and see how we can run the container in serverless Azure services in the cloud. Rainer does not expect any deep prior knowledge of Go on your side. His session should raise interest and provide enough information so you can decide whether you want to dive deeper into the Go universe.
You know API Management as the capability to manage and secure REST and SOAP APIs. As an API provider, you’ll want to monitor activity and ensure the needs of the developers and applications using your APIs are being met. As an API consumer, you'll want ease of use and a short time to your first API call.
API technologies are evolving. Are Istio und GraphQL the new rising stars, which need to be integrated into your APIs and your API Management environment?
This session intends to provide an introduction to the concepts of Istio in a service mesh context, as well as to GraphQL as a new paradigm for creating APIs. We will demonstrate some typical use cases for managing microservices and GraphQL interfaces in the context of API Management.
Most APIs built today are considered REST APIs these days, when in fact they merely exchange data via HTTP and JSON. At the same time, systems almost never act autonomously but rather live alongside others. In that context, being able to evolve an API becomes a crucial aspect in its design and the only knee-jerk, but often problematic reaction usually is: versioning.
The talk takes a step back and looks at the architectural context APIs live in and outlines the drawbacks that result from ignoring crucial parts of REST. It discusses internal VS. external APIs, whether that distinction is useful in the first place, the impact of Domain-Driven Design and how to design and specify APIs and their clients to optimize for evolvability so that changes in an API don’t break clients.
The demo part of the talk features a sample project on top of Spring Boot and Java.
Digital transformation frequently results in transitioning to API-oriented IT strategies. API-centric ecosystems have to balance two complementary goals: Giving API development teams the autonomy and flexibility to develop products as effectively as possible, and making sure that the growing and constantly evolving landscape of APIs has a level of design quality and coherence that allows API consumers to utilize this landscape effectively. This can be a challenge for IT architecture, in particular when transitioning from a more traditional view of architecture, where the main perspective was that of architecture as a top-down process that starts with modeling a system and ends with delivering a running system. In loosely coupled API-centric systems, architecture at the ecosystem level takes a distinctively different approach: It observes the creation and evolution of components and uses these observations to evolve the constraints of the ecosystem, and to provide support and tooling where necessary. Continuous Architecting is the process that supports the balance between component goals and ecosystem goals: It collects feedback from the ecosystem in the form of observations from developers and users and the organization and translates those into ways that improve and support component development.
Das API-Design ist finalisiert, die Implementierung nahezu abgeschlossen. Dann kann es also bald los gehen. Doch wie kann erreicht werden, dass das neue API auch zum Erfolg wird? Wie können Entwickler dafür begeistert werden, das API auch tatsächlich einzusetzen? Neben geschicktem Marketing ist hier vor allem eine gute Developer Experience (DX) von zentraler Bedeutung: API Reference, Dokumentation, Beispiele, Blogs, der Aufbau einer Community ... In diesem Talk erhalten angehende API-Anbieter wertvolle Tipps aus der Praxis.
Michael Frembs (ARS) und Stefan Peter (HUK-COBURG) erzählen wieso der Weg von API First zwangsläufig auch zum Einsatz von Cloud Technologien führt und welche typischen Etappen (z.B. API Design Kriterien, Architektur und Technologie Guidelines, Bereitstellung von Plattformen, Mitarbeiter-Enablement) es auf dem Weg zum digitalen Champion zu meistern gilt. Darüber hinaus gibt Stefan Peter Einblick aus Sicht der HUK-COBURG darüber, welchen strategischen Mehrwert die damit verbundenen Technologien, Architekturansätze und Methodiken im Rahmen einer digitalen Transformation liefern.
Sie verwenden RESTful Web Services zum Bereitstellen von Daten für Ihre Anwendungen? Sie denken sich: "Ja klar, was denn sonst?". Dann sollten Sie sich näher mit GraphQL beschäftigen. GraphQL ist eine Abfragesprache und wird u. a. von Facebook, GitHub und Shopify als Alternative zu RESTful Web Services eingesetzt. In dieser Session erfahren Sie, was GraphQL ist und welche Vorteile sich durch die Verwendung von GraphQL für Sie ergeben. Darüber hinaus sehen Sie, wie GraphQL server- und clientseitig verwendet werden kann. Sie lieben REST? Sie hassen REST? Sie befinden sich gefühlsmäßig irgendwo dazwischen oder denken sich: "REST, what else?" Wagen Sie den Blick über den Tellerrand! Und vielleicht verwenden auch Sie nach dieser Session GraphQL für Ihre nächste Anwendung.
Whenever we've got trouble in our bathroom - we call the plumber.
He will fix it, and we are happy again.
Would we call a plumber if we had to solve an urgent business problem? Most probably not!
Whenever our organization faces technical issues or challenges - it calls the IT-Department. The Delivery-Unit. IT delivers - paid by the work performed (We have to re-think our pretzels here as well! - later in the speech)
In most of all cases - and I’ve seen so many - APIs are treated as a technical asset - seen as a new integration layer.
Whenever this happens, organizations are reproducing their old system - their old thinking - their old habits - their Status-Quo - with APIs.
<<WHAT A FRUSTRATING, EXPENSIVE MISTAKE>>
Today’s API approaches have to enable developers (IT-Folks) to become customer-facing artists - Technology-Business cow(boys|girls)
Because: “We can't solve problems by using the same kind of thinking we used when we created them. - Albert Einstein”
There is an awareness of silos in our organizations. But these Silos are layered!
So - to tackle APIs successfully we have to get rid of Thinking-Silos -AND- Thinking-In-Layers!
My keynote will show solutions to overcome this situation. I will talk about the adoption of real API-Product-Management, demystify pseudo-agile patterns/frameworks and empower IT-People to find the right place inside their organizations and - of course - to finally be the heroes they deserve to be!
APIs are the food for the digital world. They pave the way to new business models through digital services. But APIs are just a technical enabler for an evolutionary End-to-end Architecture. They are part of a bigger journey to modernization strategies and can unlock further economic and agility benefits through a fully implemented API Economy. This session focuses on possibilities how APIs can foster this initiative, embedded in the bigger picture of Integration development using cloud native architectures.
Agiler, effizienter, innovativer - bei Mister Spex erfinden wir uns stetig neu. Unsere gewachsene IT stellt uns dabei vor technologische und kulturelle Herausforderungen. Höhere Entwicklerattraktivität, bessere Anpassbarkeit und Wartbarkeit sind unsere Motivatoren auf dem Weg in die Zukunft. Wir müssen dabei einen Weg finden, uns zu modernisieren, ohne unsere Kunden zu vernachlässigen. In unserem Vortrag beschreiben wir, wie wir es geschafft haben, mit Hilfe eines RESTful API Ansatzes unsere IT-Landschaft zu modernisieren. Wir gehen dabei auf unseren Workflow, das Toolset und die organisatorischen Maßnahmen ein, die sich auf diesem Weg herauskristallisiert haben.
In this session you will learn about the benefits of serverless for startups and why Laserhub sees a lot of potential by adopting Serverless Framework in early use cases. By limiting the scope of serverless, we balanced risk and value add, but entered a new world for development and DevOps within two weeks.
In einer Live-Coding-Session werde ich demonstrieren, wie über eine Continuous Deployment Pipeline in Kombination mit Consumer-driven Contracts und einem Pact Broker sichergestellt werden kann, dass sowohl auf der Integration Stage als auch in Produktion nur Services deployt werden (können), deren Schnittstellen kompatibel sind.
Die API Economy ist in aller Munde, fast täglich werden neue APIs von Unternehmen oder Behörden veröffentlicht. Es ist praktisch unmöglich, sich einen umfassenden Überlick selbst nur über die interessantesten öffentlich zugänglichen APIs zu verschaffen. In diesem Talk begeben wir uns auf eine kleine Rundreise durch die API-Landschaft. Es sollen einige sehr nützliche API-Angebote vorgestellt werden, die sich in zahlreichen Projekten sinnvoll einsetzen lassen. Manche dieser APIs sind recht bekannt, bieten jedoch teils ungeahnte Einsatzmöglichkeiten. Andere APIs sind (noch) relativ unbekannt, können aber dennoch eine große Hilfe darstellen. Reiseteilnehmer sind eingeladen, auch eigene API-Fundstücke kurz vorzustellen.
Come see how easy it can be to use Google Firebase to take your app idea from concept to production. In this session, you will build your own messaging application, start to finish, with support for images, markdown and connecting with friends. While building this web app, you will learn about many Firebase features, including: Firestore, cloud functions, cloud storage, hosting, authentication, security rules, client and admin SDK. The code will be in JavaScript and Node.js from a git repository, so please be prepared to start coding. You will also need a Google account to sign in to Firebase.
Exploratory Testing is a skilled multidisciplinary style of testing. Many have learned to apply it on user interfaces that naturally speak to testers as their external imagination. Yet with systems of today, it is important we move that skill of smart thinking with external imagination to interfaces hidden from users - public and private APIs. How can you use exploratory testing on something that does not have a GUI?Let’s shape up our skills of exploring both the functional and parafunctional aspects of a system through its APIs in their operating environments, without forgetting developer experience of having to maintain and troubleshoot these systems. Let’s learn to be intentional with our APIs, instead of being accidental - through delivering relevant, timely feedback. Intertwining test automation and exploration, we include considerations of the best for today and for the future. For great testing bringing value now as well as when we are not around, we need to be great at testing - uncovering relevant information - and programming - building maintainable test systems. At the core of all of this is learning. What we lack in a set of skills, we can compensate through collaboration.
Wenn ein API erst einmal live ist, ist es nicht mehr so einfach, es zu ändern. Doch jede noch so gut definierte Schnittstelle kommt irgendwann an den Punkt, an dem sie weiterentwickelt werden muss; sei es nur, weil sich die Anforderungen geändert haben. Dann stellt sich die Frage, ob die Schnittstelle abwärtskompatibel weiterentwickelt werden kann oder ob eine neue Version gebaut werden muss. Wie muss sich dann der Client verhalten, damit er weiter funktioniert? Neben den technischen Herausforderungen, die zu meistern sind, stellt diese Session aus der Praxiserfahrung heraus vor, welche Konzepte in Entwicklung, Dokumentation und Deployment verwendet werden können, um client- und serverseitig nicht in der Versionshölle zu landen.
"API calls are either successful or they fail" – at least that’s the concept current web protocols are based upon. But in the real world, it isn’t always that simple. There are use cases where a 3rd party system returns something that can’t be defined as a clear error, but returning a http status code of 200 OK is also wrong. For those cases, every vendor has its own way of communicating to the client what has gone wrong in the backend. So depending on the microservice you want to integrate into your system, you will have to work with very different ideas of how errors are being communicated back to you. This is why we need to find a common way to communicate those edge cases.
Most approaches to testing test individual examples. This is often not enough to tease out rare but realistic edge cases. As a result, it takes a large number of individual tests to really be confident that our API is ready for deployment: This is a lot of work. What if we could generate test cases automatically? Doing so leads to thinking about tests not in terms of individual examples, but general properties, and from there to an approach called property-based testing or QuickCheck. QuickCheck generates tests from properties. It has its origins in functional programming, and has been a crucial tool in eliminating bugs from many complex software projects. But QuickCheck does more than help find bugs: It encourages thinking about our API in terms of properties, and this style of thinking often leads to interesting domain insights and architectural improvements. The talk gives an introduction to QuickCheck and shows how to apply it in realistic projects.