Sachin Agarwal, SOA Software VP of Product Marketing, explains the frenzy around the mass development and adoption of APIs. In this presentation, he describes the business and technology implications of developing an API stratgy.
APIs have revolutionized how companies build new marketing channels, access new customers, and create ecosystems. Enabling all this requires the exposure of APIs to a broad range of partners and developers—and potential threats.
Learn more about the latest API security issues.
Developer Support Models: Calibrating Service Level to CommitmentNordic APIs
Developer support models across the industry range from DIY to premium ‘hand-holding’. Program managers are constantly challenged to pick the right mix of support elements without driving up costs. When reviewing support models, calibrating the level of service to the level of developer commitment seems to be the key to making support an effective element of overall program strategy. This session will review industry benchmark research on developer support: how leading programs are using models ranging from DIY to premium in service of building a targeted ecosystem and how they are balancing this with expectations of developer commitment.
Be My API How to Implement an API Strategy Everyone will Love CA API Management
Mike Amundsen,
Principal API Architect, Layer 7 Technologies
Mike is the author of Building Hypermedia APIs with HTML5 & Node and is a regular speaker at leading industry events on the subject of API design, Web application development and cloud computing.
Learn how to create and publish APIs that will help your business thrive and grow
February 7, 2013
9am PST | 12pm EST
Building great APIs is about more than just design; it requires detailed, thoughtful execution. Your API strategy needs to meet the business requirements of your organization but it must also be flexible enough to meet your developer community’s diverse needs. This webinar with Mike Amundsen, Layer 7's Principal API Architect, will examine the key foundational elements necessary for a solid API implementation strategy.
You Will Learn
Align API design with business goals
Architect flexible and robust APIs that are developer-accessible
Design for multiple client platforms (Web, mobile and cloud)
Implement USE methodology, versioning, reusability and hypermedia
Address issues around security, identity, social integration, reliability and scalability
Presented By
WSO2Con EU 2015: Towards a Winning API StrategyWSO2
WSO2Con EU 2015: Towards a Winning API Strategy
Today, every enterprise agrees that there is a pressing need for business APIs. However, it’s the right API strategy that will make business APIs a winning one.
This session will explain how you could formulate a winning API strategy, and will particularly focus on the following areas:
What are the key ingredients in defining a winning API strategy?
How should the strategy be converted into a set of action items that will create a winning combination?
How can WSO2’s API Management capabilities help?
It will also touch on some real customer scenarios where WSO2′s platform has been a key part in implementing a winning API strategy for these enterprises.
Presenter:
Sumedha Rubasinghe
Director – API Architecture,
WSO2
apidays LIVE Paris - The Business of APIs by Jed Ngapidays
apidays LIVE Paris - Responding to the New Normal with APIs for Business, People and Society
December 8, 9 & 10, 2020
The Business of APIs: Lessons from building the world's largest API Marketplace
Jed Ng, Tech & API Investor
Sachin Agarwal, SOA Software VP of Product Marketing, explains the frenzy around the mass development and adoption of APIs. In this presentation, he describes the business and technology implications of developing an API stratgy.
APIs have revolutionized how companies build new marketing channels, access new customers, and create ecosystems. Enabling all this requires the exposure of APIs to a broad range of partners and developers—and potential threats.
Learn more about the latest API security issues.
Developer Support Models: Calibrating Service Level to CommitmentNordic APIs
Developer support models across the industry range from DIY to premium ‘hand-holding’. Program managers are constantly challenged to pick the right mix of support elements without driving up costs. When reviewing support models, calibrating the level of service to the level of developer commitment seems to be the key to making support an effective element of overall program strategy. This session will review industry benchmark research on developer support: how leading programs are using models ranging from DIY to premium in service of building a targeted ecosystem and how they are balancing this with expectations of developer commitment.
Be My API How to Implement an API Strategy Everyone will Love CA API Management
Mike Amundsen,
Principal API Architect, Layer 7 Technologies
Mike is the author of Building Hypermedia APIs with HTML5 & Node and is a regular speaker at leading industry events on the subject of API design, Web application development and cloud computing.
Learn how to create and publish APIs that will help your business thrive and grow
February 7, 2013
9am PST | 12pm EST
Building great APIs is about more than just design; it requires detailed, thoughtful execution. Your API strategy needs to meet the business requirements of your organization but it must also be flexible enough to meet your developer community’s diverse needs. This webinar with Mike Amundsen, Layer 7's Principal API Architect, will examine the key foundational elements necessary for a solid API implementation strategy.
You Will Learn
Align API design with business goals
Architect flexible and robust APIs that are developer-accessible
Design for multiple client platforms (Web, mobile and cloud)
Implement USE methodology, versioning, reusability and hypermedia
Address issues around security, identity, social integration, reliability and scalability
Presented By
WSO2Con EU 2015: Towards a Winning API StrategyWSO2
WSO2Con EU 2015: Towards a Winning API Strategy
Today, every enterprise agrees that there is a pressing need for business APIs. However, it’s the right API strategy that will make business APIs a winning one.
This session will explain how you could formulate a winning API strategy, and will particularly focus on the following areas:
What are the key ingredients in defining a winning API strategy?
How should the strategy be converted into a set of action items that will create a winning combination?
How can WSO2’s API Management capabilities help?
It will also touch on some real customer scenarios where WSO2′s platform has been a key part in implementing a winning API strategy for these enterprises.
Presenter:
Sumedha Rubasinghe
Director – API Architecture,
WSO2
apidays LIVE Paris - The Business of APIs by Jed Ngapidays
apidays LIVE Paris - Responding to the New Normal with APIs for Business, People and Society
December 8, 9 & 10, 2020
The Business of APIs: Lessons from building the world's largest API Marketplace
Jed Ng, Tech & API Investor
IT architects and developers have long recognized APIs as an evolution and continuation of integration-based architectures used within enterprise IT. But this is a limited view. APIs have become the foundational framework for development of scalable enterprise applications that connect user experiences to back-end data and services.
How will this API-centric architecture play a role in your application systems and in your business? Join Ed Anuff and Brian Pagano as they discuss the many important implications of API-centric architecture.
Learn:
- the characteristics of an API-centric architecture
- how APIs are influencing front-end, back-end, and app-to-app systems
- how APIs change the way data is leveraged
- why traditional architecture cannot address new business challenges
Pain Points In API Development? They’re EverywhereNordic APIs
There’s an inherent tension for organizations doing API development: how to keep both your API developers as well as your infrastructure happy, at the same time. Decoupling front-end and back-end development allows parallel development, and helps keep your front-end, middle-end, and back-end efforts working asynchronously. This speeds progress, but requires far more – and far better – collaboration to be successful. Even an independent developer working with APIs requires good collaboration tools.
In this talk, Abhinav Asthana will provide tips on how to improve in API development using collaboration tools like executable API descriptions, API mock servers, and documentation. He will include specific examples of how companies (such as VMware, Coursera, and AMC Theatres) have used collaboration to attain more agile development, to onboard developers, and to ensure input from all participants/stakeholders.
APIs Are Forever - How to Design Long-Lasting APIsLaunchAny
Teams often struggle with balancing the complexity of legacy applications, limited time, and limited resources when designing APIs. The result is often the release of less-than-ideal API design that meets the immediate needs of the client but misses opportunities for longer-term value. This talk explores systems design and domain-driven design (DDD) for API design thinking and how to apply this technique to your design process to create a clear, well-designed, long-lasting API. Presented at API Strategy and Practice 2015
apidays LIVE LONDON - Protecting financial-grade APIs - Getting the right API...apidays
apidays LIVE LONDON - The Road to Embedded Finance, Banking and Insurance with APIs
Protecting financial-grade APIs - Getting the right API Security stack!
Isabelle Mauny, CTO at 42Crunch
Best Practices for API Design to Keep Your App Secure, Scalable & EfficientNordic APIs
With a plethora of best practices for designing APIs, many application teams end up focusing on details that may not be a high priority when compared to design principles that can keep your application secure, scalable and efficient. In this session, we will explore the critical best practices around API design including API versioning, error handling, and microservices architectures for decoupling functionality. We will also explore some the crucial security principles that should be applied when designing the business logic. These include pagination restrictions to prevent DDoS attacks as well as proper identity governance implementation to mitigate API-specific vulnerabilities like data breaches as a result of the incorrect assignment of RBAC roles or ABAC rules that control access to resources.
Lessons Learned from Revamping Our Doc SitePronovix
Learn what went well and what didn’t, when Ilona, a technical writer, and Prabhjot, a software engineer, share the story of revamping the developer documentation website at Twitch. Some hints: getting it done required more than just engineering, content, and design. Together they learned how to “manage up” and that the whole project went better because they worked so well as a team.
Main focus of the talk is to communicate some key concepts of designing/implementing APIs based on an enterprise grade API Standards and Guidelines. We will try to handcraft few API recipes(i.e. implementation design) with real-life examples mixed with a live coding session. While working on each recipe, we will delve into the rationale behind design decisions and best practices. We believe that these concepts will help a developer build a comprehensive API solution from scratch.
The API Management journey of the British Broadcasting Corporation (BBC), a public service organisation that serves audiences around the world. From no API intelligence to a distributed solution supporting dozens of autonomous teams.
Our engineers will talk about how they have delivered our custom proxy software at scale, how they work towards not being a single point of failure and how being at the centre of the API traffic enables them to provide extra value services like SLA Monitoring for our engineering teams.
We’ll explore how new authentication mechanisms are emerging and how we as a team facilitate the expanding API management landscape, considering the independent nature of our products.
APIs are the lynchpin to the success of your digital business. Explore how you can effectively design, secure, monitor and manage APIs across the enterprise.
The enterprise has learned from the consumer API movement and recognized the value of creating developer communities to drive the adoption and productive use of APIs. Building an API community internally, however, requires a different approach from what has worked in the consumer space. Business objectives for APIs and measurements of success tend to be different for internal APIs. Security and access controls are not the same, of course, and back-end systems tend to be quite a lot more complex in the enterprise than they are in public-facing API situations. This webinar explores the challenges and best practices inherent in building an internal API community that serves an enterprise’s business and technological goals.
apidays LIVE Hong Kong 2021 - Automating the API Product Lifecycle by Jeremy ...apidays
apidays LIVE Hong Kong 2021 - API Ecosystem & Data Interchange
August 25 & 26, 2021
Automating the API Product Lifecycle
Jeremy Glassenberg, Product Lead, APIs at Docusign
I Love APIs 2015: Scaling Mobile-focused Microservices at VerizonApigee | Google Cloud
I Love APIs 2015
Vidhya Narayanan, Verizon
Chris Webster, Verizon
https://www.go90.com/learn
Vidhya Narayanan, Director of Engineering, and Christopher Webster, Associate Fellow, Verizon, discuss how Verizon created and launched a mobile-first over the top video platform using over 100 microservices. This session at I Love APIs 2015 covered the architecture for deployment and management of microservices, the technologies used to address scale, availability, and security issues and the pitfalls encountered along the way.
Dependency Down, Flexibility Up – The Benefits of API-First DevelopmentNordic APIs
The tech industry is moving toward cloud and serverless infrastructures. This shift isn’t without its challenges. Complexity is growing in microservices stacks, containerization, and continuous delivery. With a code-first approach, services can be vulnerable to development bottlenecks and program breakage, especially as complexity grows. This is where API-first development comes in.
The main difference between code-first and API-first is that instead of starting with code, API-first programs begin with design, planning, mocks, and tests. Having a planned infrastructure during development and before implementation allows new features to be built as independent services. So, when a particular service is broken or overloaded, remaining services can still function successfully.
In this talk, Ankit Sobti will discuss how an API-first approach creates the backbone to robust, powerful programs that are resistant to breakage. In addition, he will walk through using mocks and tests to optimize feedback in early development, and share concrete examples of API-first development. By the end of this session, you will understand why and how API-first has the potential to create higher functioning and more flexible systems in the future.
Applying Domain-Driven Design to APIs and Microservices - Austin API MeetupLaunchAny
A look at the stories our APIs tell, the importance of API design, and how systems design and domain-driven design can be used to build a long-lasting API design
GlueCon 2018: Are REST APIs Still Relevant Today?LaunchAny
A look at common API styles available today, a look back at historical API styles, and guidance for selecting the right API styles for your organization. Deep-dive of HTTP, mentioned in the presentation, can be found at: http://bit.ly/power-http
Content Strategy and Developer Engagement for DevPortalsAxway
Slides from Write the Docs Ottawa Meet Up at Shopify HQ in Canada, June 24, 2019
We’ll walk through 5 scenarios and concrete ways of reaching a developer community for frictionless and increased engagement.
IT architects and developers have long recognized APIs as an evolution and continuation of integration-based architectures used within enterprise IT. But this is a limited view. APIs have become the foundational framework for development of scalable enterprise applications that connect user experiences to back-end data and services.
How will this API-centric architecture play a role in your application systems and in your business? Join Ed Anuff and Brian Pagano as they discuss the many important implications of API-centric architecture.
Learn:
- the characteristics of an API-centric architecture
- how APIs are influencing front-end, back-end, and app-to-app systems
- how APIs change the way data is leveraged
- why traditional architecture cannot address new business challenges
Pain Points In API Development? They’re EverywhereNordic APIs
There’s an inherent tension for organizations doing API development: how to keep both your API developers as well as your infrastructure happy, at the same time. Decoupling front-end and back-end development allows parallel development, and helps keep your front-end, middle-end, and back-end efforts working asynchronously. This speeds progress, but requires far more – and far better – collaboration to be successful. Even an independent developer working with APIs requires good collaboration tools.
In this talk, Abhinav Asthana will provide tips on how to improve in API development using collaboration tools like executable API descriptions, API mock servers, and documentation. He will include specific examples of how companies (such as VMware, Coursera, and AMC Theatres) have used collaboration to attain more agile development, to onboard developers, and to ensure input from all participants/stakeholders.
APIs Are Forever - How to Design Long-Lasting APIsLaunchAny
Teams often struggle with balancing the complexity of legacy applications, limited time, and limited resources when designing APIs. The result is often the release of less-than-ideal API design that meets the immediate needs of the client but misses opportunities for longer-term value. This talk explores systems design and domain-driven design (DDD) for API design thinking and how to apply this technique to your design process to create a clear, well-designed, long-lasting API. Presented at API Strategy and Practice 2015
apidays LIVE LONDON - Protecting financial-grade APIs - Getting the right API...apidays
apidays LIVE LONDON - The Road to Embedded Finance, Banking and Insurance with APIs
Protecting financial-grade APIs - Getting the right API Security stack!
Isabelle Mauny, CTO at 42Crunch
Best Practices for API Design to Keep Your App Secure, Scalable & EfficientNordic APIs
With a plethora of best practices for designing APIs, many application teams end up focusing on details that may not be a high priority when compared to design principles that can keep your application secure, scalable and efficient. In this session, we will explore the critical best practices around API design including API versioning, error handling, and microservices architectures for decoupling functionality. We will also explore some the crucial security principles that should be applied when designing the business logic. These include pagination restrictions to prevent DDoS attacks as well as proper identity governance implementation to mitigate API-specific vulnerabilities like data breaches as a result of the incorrect assignment of RBAC roles or ABAC rules that control access to resources.
Lessons Learned from Revamping Our Doc SitePronovix
Learn what went well and what didn’t, when Ilona, a technical writer, and Prabhjot, a software engineer, share the story of revamping the developer documentation website at Twitch. Some hints: getting it done required more than just engineering, content, and design. Together they learned how to “manage up” and that the whole project went better because they worked so well as a team.
Main focus of the talk is to communicate some key concepts of designing/implementing APIs based on an enterprise grade API Standards and Guidelines. We will try to handcraft few API recipes(i.e. implementation design) with real-life examples mixed with a live coding session. While working on each recipe, we will delve into the rationale behind design decisions and best practices. We believe that these concepts will help a developer build a comprehensive API solution from scratch.
The API Management journey of the British Broadcasting Corporation (BBC), a public service organisation that serves audiences around the world. From no API intelligence to a distributed solution supporting dozens of autonomous teams.
Our engineers will talk about how they have delivered our custom proxy software at scale, how they work towards not being a single point of failure and how being at the centre of the API traffic enables them to provide extra value services like SLA Monitoring for our engineering teams.
We’ll explore how new authentication mechanisms are emerging and how we as a team facilitate the expanding API management landscape, considering the independent nature of our products.
APIs are the lynchpin to the success of your digital business. Explore how you can effectively design, secure, monitor and manage APIs across the enterprise.
The enterprise has learned from the consumer API movement and recognized the value of creating developer communities to drive the adoption and productive use of APIs. Building an API community internally, however, requires a different approach from what has worked in the consumer space. Business objectives for APIs and measurements of success tend to be different for internal APIs. Security and access controls are not the same, of course, and back-end systems tend to be quite a lot more complex in the enterprise than they are in public-facing API situations. This webinar explores the challenges and best practices inherent in building an internal API community that serves an enterprise’s business and technological goals.
apidays LIVE Hong Kong 2021 - Automating the API Product Lifecycle by Jeremy ...apidays
apidays LIVE Hong Kong 2021 - API Ecosystem & Data Interchange
August 25 & 26, 2021
Automating the API Product Lifecycle
Jeremy Glassenberg, Product Lead, APIs at Docusign
I Love APIs 2015: Scaling Mobile-focused Microservices at VerizonApigee | Google Cloud
I Love APIs 2015
Vidhya Narayanan, Verizon
Chris Webster, Verizon
https://www.go90.com/learn
Vidhya Narayanan, Director of Engineering, and Christopher Webster, Associate Fellow, Verizon, discuss how Verizon created and launched a mobile-first over the top video platform using over 100 microservices. This session at I Love APIs 2015 covered the architecture for deployment and management of microservices, the technologies used to address scale, availability, and security issues and the pitfalls encountered along the way.
Dependency Down, Flexibility Up – The Benefits of API-First DevelopmentNordic APIs
The tech industry is moving toward cloud and serverless infrastructures. This shift isn’t without its challenges. Complexity is growing in microservices stacks, containerization, and continuous delivery. With a code-first approach, services can be vulnerable to development bottlenecks and program breakage, especially as complexity grows. This is where API-first development comes in.
The main difference between code-first and API-first is that instead of starting with code, API-first programs begin with design, planning, mocks, and tests. Having a planned infrastructure during development and before implementation allows new features to be built as independent services. So, when a particular service is broken or overloaded, remaining services can still function successfully.
In this talk, Ankit Sobti will discuss how an API-first approach creates the backbone to robust, powerful programs that are resistant to breakage. In addition, he will walk through using mocks and tests to optimize feedback in early development, and share concrete examples of API-first development. By the end of this session, you will understand why and how API-first has the potential to create higher functioning and more flexible systems in the future.
Applying Domain-Driven Design to APIs and Microservices - Austin API MeetupLaunchAny
A look at the stories our APIs tell, the importance of API design, and how systems design and domain-driven design can be used to build a long-lasting API design
GlueCon 2018: Are REST APIs Still Relevant Today?LaunchAny
A look at common API styles available today, a look back at historical API styles, and guidance for selecting the right API styles for your organization. Deep-dive of HTTP, mentioned in the presentation, can be found at: http://bit.ly/power-http
Content Strategy and Developer Engagement for DevPortalsAxway
Slides from Write the Docs Ottawa Meet Up at Shopify HQ in Canada, June 24, 2019
We’ll walk through 5 scenarios and concrete ways of reaching a developer community for frictionless and increased engagement.
With Apache Kafka’s rise for event-driven architectures, developers require a specification to design effective event-driven APIs. AsyncAPI has been developed based on OpenAPI to define the endpoints and schemas of brokers and topics. For Kafka applications, the broker’s design to handle high throughput serialized payloads brings challenges for consumers and producers managing the structure of the message. For this reason, a registry becomes critical to achieve schema governance. Apicurio Registry is an end-to-end solution to store API definitions and schemas for Kafka applications. The project includes serializers, deserializers, and additional tooling. The registry supports several types of artifacts including OpenAPI, AsyncAPI, GraphQL, Apache Avro, Google protocol buffers, JSON Schema, Kafka Connect schema, WSDL, and XML Schema (XSD). It also checks them for validity and compatibility.
In this session, we will be covering the following topics:
● The importance of having a contract-first approach to event-driven APIs
● What is AsyncAPI, and how it helps to define Kafka endpoints and schemas
● The Kafka challenges on message structure when serializing and deserializing
● Introduction to Apicurio Registry and schema management for Kafka
● Examples of how to use Apicurio Registry with popular Java frameworks like Spring and Quarkus
What’s behind a high quality web API? Ensure your APIs are more than just a ...Kim Clark
Web APIs have now become as important as websites for some enterprises. Dreaming up an attractive set of data resources to expose to your consumers is a critical step, but it's just the beginning. In the world of APIs, standards are rare, so common conventions are everything. Which should you choose, and how do you apply them to your data model? What architecture will ensure your APIs are robust, scalable, and secure? How do you ensure data integrity in an environment without transactionality? How will you prepare for huge changes in scale? How do you join your API world with your existing enterprise integration and SOA? Attendees will learn design practices to ensure their APIs are both attractive and consumable.
API Gateways are going through an identity crisisChristian Posta
API Gateways provide functionality like rate limiting, authentication, request routing, reporting, and more. If you've been following the rise in service-mesh technologies, you'll notice there is a lot of overlap with API Gateways when solving some of the challenges of microservices. If service mesh can solve these same problems, you may wonder whether you really need a dedicated API Gateway solution?
The reality is there is some nuance in the problems solved at the edge (API Gateway) compared to service-to-service communication (service mesh) within a cluster. But with the evolution of cluster-deployment patterns, these nuances are becoming less important. What's more important is that the API Gateway is evolving to live at a layer above service mesh and not directly overlapping with it. In other words, API Gateways are evolving to solve application-level concerns like aggregation, transformation, and deeper context and content-based routing as well as fitting into a more self-service, GitOps style workflow.
In this talk we put aside the "API Gateway" infrastructure as we know it today and go back to first principles with the "API Gateway pattern" and revisit the real problems we're trying to solve. Then we'll discuss pros and cons of alternative ways to implement the API Gateway pattern and finally look at open source projects like Envoy, Kubernetes, and GraphQL to see how the "API Gateway pattern" actually becomes the API for our applications while coexisting nicely with a service mesh (if you adopt a service mesh).
Learn about the state of Serverless after AWS re:Invent 2020. Check out the most impactful new features, and use cases for the new capabilities. Event recording (including 1hr long Q&A) is at http://YouTube.ServerlessToronto.org
LINKS FROM THE MEETUP CHAT:
Best practices in Product Management https://www.meetup.com/lean-product/
Some good PMs (Product Managers) will be here https://www.productfaculty.com/cpo-mastery
re:Invent 2020 Sessions https://virtual.awsevents.com/agenda
Amazon Aurora Serverless v2 - Instant scaling for demanding workloads https://virtual.awsevents.com/media/1_3nlad51o
OpenTelemetry & AWS X-Ray https://aws.amazon.com/blogs/opensource/enhancing-aws-x-ray-support-in-opentelemetry-javascript-sdk/
Adrian Cockcroft’s architecture trends and topics for 2021 https://virtual.awsevents.com/esearch/search?keyword=cockcroft
Dirk Froehner's talk "Application integration patterns for microservices" https://virtual.awsevents.com/media/1_6zks63br
"Tim Bray and Friends | Messaging Series" https://aws.amazon.com/messaging/twitch/
"How I started building serverless apps - the Serverless Coffee Break with Emily Shea" https://www.youtube.com/watch?v=oxHnUFMRWu8
Our Knowledge sponsor https://www.manning.com/
4 Serverless events already scheduled for 2021, RSVP at https://www.meetup.com/Serverless-Toronto/events
LINKS FROM THE PRESENTATION:
https://twitter.com/jbesw
1 ms billing https://s12d.com/1ms
Container image support for AWS Lambda https://s12d.com/OCI
https://s12d.com/extensions-intro
https://s12d.com/extensions-building
https://s12d.com/extensions-logs
Decoupling serverless workloads with Amazon EventBridge (James Beswick) https://virtual.awsevents.com/media/1_gyzid3q3
AWS Lambda – Part 1: Optimizing your serverless applications (Chris Munns) https://virtual.awsevents.com/media/1_bhnvfdgz
Best practices for securing your serverless applications (Rob Sutter) https://virtual.awsevents.com/media/1_zchhd4oh
API Gateway – Beyond the proxy (Eric Johnson) https://virtual.awsevents.com/media/1_hgw8wdl7
The serverless LAMP stack (Ben Smith) https://virtual.awsevents.com/media/1_ajbfgmdl
Becoming proficient with serverless application observability (Julian Wood) https://virtual.awsevents.com/media/1_t0qj8lcg
Resources for learning AWS https://ServerlessLand.com/learn
API Sandbox: Empowering Developer Experience (DX)Faisal Banaeamah
It explores different architecture design patterns and options to provide #apisandbox within developer portal and empower developer experience. It also shows its relationship with API-First.
AWS August Webinar Series - Building Serverless Backends with AWS Lambda and ...Amazon Web Services
AWS Lambda is a compute service that runs your code in response to triggers and automatically manages the compute resources for you. Amazon API Gateway is a fully managed service that makes it easy for developers to publish, maintain, monitor, and secure APIs at any scale.
This webinar will familiarize you with the basics of AWS Lambda and Amazon API Gateway and demonstrate how to build web, mobile, and IoT backends using these services. You will learn how to setup API endpoints that trigger AWS Lambda functions to handle mobile, web, IoT, and 3rd party API requests. You will also learn how to use Lambda to read and write to DynamoDB.
Learning Objectives:
Understand key AWS Lambda and Amazon API Gateway features
Learn how to set up a serverless backend using Amazon API Gateway and AWS Lambda
Explore sample use cases, best practices and tips on using AWS Lambda with Amazon API Gateway
Oracle API Platform Cloud Service Best Practices & Lessons Learntluisw19
I did this presentation in Split/Croatia on March 2017 where I shared our experiences and insights when implementing the Oracle API Platform Cloud Service.
apidays LIVE Jakarta - API Sandbox: empowering Developer Experience (DX) by F...apidays
apidays LIVE Jakarta 2021 - Accelerating Digitisation
February 24, 2021
API Sandbox: empowering Developer Experience (DX)
Faisal Banaeamah, Chief Architect at Solutions by STC
As soon as we start working on an API, architecture issues arise. Many mistaken common beliefs turn out to be fiction in this area. A poorly designed API architecture will lead to misuse or – even worse – not be used at all by its intended clients: application developers.
To facilitate and accelerate design and development of your APIs, we share our vision and beliefs with you in this Reference Card. They come from our direct experience on API projects.
This was presented by me in AWS Meetup in Riyadh. I spoke about core dimensions of API management and Amazon API Gateway. It covers API fundamentals as well as security and architecture principles using AWS services.
These slides focus on documentation for REST APIs. See http://idratherbewriting.com for more detail. For the video recording, see http://youtu.be/0yfNd7tzH2Q. This deep dive is the second slide deck I used in the presentation.
We present how Cisco Engineering uses the OpenAPI specifications to drive API quality and state-of-the-art developer experience. We then describe OpenAPI best practices, tools and processes built internally and opensource'd. Finally, we cover lessons learnt when standardizing on OAS for organizations with a massive API portfolio.
This talk was delivered at API Days Global/Paris on December 14th
Kubernetes & AI - Beauty and the Beast !?! @KCD Istanbul 2024Tobias Schneck
As AI technology is pushing into IT I was wondering myself, as an “infrastructure container kubernetes guy”, how get this fancy AI technology get managed from an infrastructure operational view? Is it possible to apply our lovely cloud native principals as well? What benefit’s both technologies could bring to each other?
Let me take this questions and provide you a short journey through existing deployment models and use cases for AI software. On practical examples, we discuss what cloud/on-premise strategy we may need for applying it to our own infrastructure to get it to work from an enterprise perspective. I want to give an overview about infrastructure requirements and technologies, what could be beneficial or limiting your AI use cases in an enterprise environment. An interactive Demo will give you some insides, what approaches I got already working for real.
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024Albert Hoitingh
In this session I delve into the encryption technology used in Microsoft 365 and Microsoft Purview. Including the concepts of Customer Key and Double Key Encryption.
GraphRAG is All You need? LLM & Knowledge GraphGuy Korland
Guy Korland, CEO and Co-founder of FalkorDB, will review two articles on the integration of language models with knowledge graphs.
1. Unifying Large Language Models and Knowledge Graphs: A Roadmap.
https://arxiv.org/abs/2306.08302
2. Microsoft Research's GraphRAG paper and a review paper on various uses of knowledge graphs:
https://www.microsoft.com/en-us/research/blog/graphrag-unlocking-llm-discovery-on-narrative-private-data/
Securing your Kubernetes cluster_ a step-by-step guide to success !KatiaHIMEUR1
Today, after several years of existence, an extremely active community and an ultra-dynamic ecosystem, Kubernetes has established itself as the de facto standard in container orchestration. Thanks to a wide range of managed services, it has never been so easy to set up a ready-to-use Kubernetes cluster.
However, this ease of use means that the subject of security in Kubernetes is often left for later, or even neglected. This exposes companies to significant risks.
In this talk, I'll show you step-by-step how to secure your Kubernetes cluster for greater peace of mind and reliability.
Neuro-symbolic is not enough, we need neuro-*semantic*Frank van Harmelen
Neuro-symbolic (NeSy) AI is on the rise. However, simply machine learning on just any symbolic structure is not sufficient to really harvest the gains of NeSy. These will only be gained when the symbolic structures have an actual semantics. I give an operational definition of semantics as “predictable inference”.
All of this illustrated with link prediction over knowledge graphs, but the argument is general.
LF Energy Webinar: Electrical Grid Modelling and Simulation Through PowSyBl -...DanBrown980551
Do you want to learn how to model and simulate an electrical network from scratch in under an hour?
Then welcome to this PowSyBl workshop, hosted by Rte, the French Transmission System Operator (TSO)!
During the webinar, you will discover the PowSyBl ecosystem as well as handle and study an electrical network through an interactive Python notebook.
PowSyBl is an open source project hosted by LF Energy, which offers a comprehensive set of features for electrical grid modelling and simulation. Among other advanced features, PowSyBl provides:
- A fully editable and extendable library for grid component modelling;
- Visualization tools to display your network;
- Grid simulation tools, such as power flows, security analyses (with or without remedial actions) and sensitivity analyses;
The framework is mostly written in Java, with a Python binding so that Python developers can access PowSyBl functionalities as well.
What you will learn during the webinar:
- For beginners: discover PowSyBl's functionalities through a quick general presentation and the notebook, without needing any expert coding skills;
- For advanced developers: master the skills to efficiently apply PowSyBl functionalities to your real-world scenarios.
Software Delivery At the Speed of AI: Inflectra Invests In AI-Powered QualityInflectra
In this insightful webinar, Inflectra explores how artificial intelligence (AI) is transforming software development and testing. Discover how AI-powered tools are revolutionizing every stage of the software development lifecycle (SDLC), from design and prototyping to testing, deployment, and monitoring.
Learn about:
• The Future of Testing: How AI is shifting testing towards verification, analysis, and higher-level skills, while reducing repetitive tasks.
• Test Automation: How AI-powered test case generation, optimization, and self-healing tests are making testing more efficient and effective.
• Visual Testing: Explore the emerging capabilities of AI in visual testing and how it's set to revolutionize UI verification.
• Inflectra's AI Solutions: See demonstrations of Inflectra's cutting-edge AI tools like the ChatGPT plugin and Azure Open AI platform, designed to streamline your testing process.
Whether you're a developer, tester, or QA professional, this webinar will give you valuable insights into how AI is shaping the future of software delivery.
13. Prelude Wrap-up
So.. we don't want to be there
This talk doesn't focus about HTTP RESTful API conventions
How can we do it better then?
17
14. About Me
18
Amir Zuker
Mentor, leader, architect, developer, instructor, author and speaker
Over 20 years of experience in the field
Leads teams and R&D divisions
Several publications and contributions
Head of Web and Mobile at CodeValue
15. Agenda
Public API as a Product
Beyond API Features
Subscriptions and Identity
Spec Authoring
Versioning
Design Philosophy
19
22. Build What You Need, and Build It Well
Clarify requirements
Understand the use-cases involved
Unclear? perhaps postpone it or roll it out as an alpha version
Creativity and generosity can be an Achilles heel
KISS
Build good API’s
26
26. Beyond API Features
Routing and load balancing
Discovery
IP access listing
Audit, analytics and billing
Rate-limiting
Content transformation
Aggregations
Security, PEP (e.g., sanitation)
Telemetry and logging
Versioning
Caching
Circuit breaker
Protocol bridging
Subscription and AUTH
27. Beyond API Features
Many things to consider and take care of
Can elevate concerns from the application code
Leverage existing tools, platforms and services, e.g.,
APIM and API Gateways
Service Mesh
API Gateway and Service Mesh are not the same
Nor is it mutually exclusive
SaaS / OTS / OSS / DIY
31
34. Identity and Auth
What type of integration is needed?
Need to identify individual identities and possibly SSO?
Identity federation or synchronization
Tenant trust
Etc.
What type of protocol and credentials?
Basic, OAuth, OAuth2, OpenID, OpenID Connect
Id + Secret / Tokens (e.g. jwt) / Certificates / API keys
39
35. API Keys + Token Exchange
40
Client
Client
Client
API Gateway
Cache
Inventory
Service
Orders
Service
Inventory
Service
Inventory
Service
Orders
Service
Orders
Service
GET http://host:port/api/v1/books/0?apiKey=30c050f7fdfe466b9442570ae77dbc8a
X-API-KEY: 30c050f7fdfe466b9442570ae77dbc8a
...
IdM
GET http://internal:port/api/books/0
Authorization: Bearer asdaSXAD2dsfsdVSDFSDsad..
...
42. Auto Generation
Auto generate as much as possible
Tests and validators
Changes and release notes
Implementation (contract first)
Client-side projects and SDK's
Might require additional work
Can adjust to specific needs
49
43. Documentation
API lives or dies by its docs
Document your API’s
API surface
General concerns
Etc.
API Explorer
SaaS / OTS / OSS / DIY
46. Versioning Concerns
Commitment
Docs and release notes
Communication
Tests, QA and releases
Processes and workflows
Environment versions
Breaking changes
System's multi-version support
Codebase and conventions
From a request to a version
53
47. Semantic Versioning
Major
Often include breaking changes
Minor
Expansion of the previous version
Non-breaking changes only
Patch
Internal changes or fixes
No new definitions
No removal of definitions
54
Source
48. Breaking Changes
Know what breaks
Not just the contract, behavior and SLA too
Test and validate
Prefer expansion
55
Source
49. Commitment
Decide what to commit to
Long-term / short-term
Example:
New major every 2 years, 1 year side-by-side, 6 months beta
Commit to 2 major versions at any point in time
56
2021 2022 2023 2024 2025 2026 2027 2028
GA
v1 EoL
GA EoL
v2 beta
dev
GA EoL
beta
dev
v3
GA
beta
dev
v4
50. Multiple Versions
How to support multiple versions?
Side-by-side (major only?)
Routing + transformation
Code + transformation
Hybrid
How to correlate a request to a version?
URL (host, path, query)
Headers (standard, custom)
Media type
Mixed
57
GET /books
Host: api.fancybooks.com
Accept: application/json
X-API-Version: 2
GET /v1/books
Host: api.fancybooks.com
Accept: application/json
GET /books?v=2020-05-27
Host: api.fancybooks.com
Accept: application/json
GET /books
Host: apiv1.fancybooks.com
Accept: application/json
GET /books
Host: api.fancybooks.com
Accept: application/vnd.fbooks.v1+json
62. Recap
Public API as a product
Beyond API Features
Subscriptions and Identity
Spec Authoring
Versioning
Design Philosophy
69
63. Public API is a Product
In every aspect..
Processes and workflows
Tools, platforms and technologies
Pipelines, tests, releases
Can do agility first, maturity later
Different lengths, mileage may vary
70
APIM
Lifecycle
Define
Design
Version
Mock
Develop
Test
Deploy
Publish
Monitor
Engage
Monetize
64. Key Takeaways
There are many concerns to take care of
Subscriptions, identities, security, observability, analytics, billing, etc.
There are many tools, technologies, platforms and services to choose from
Choose what coexists well with your platform
API gateways and service mesh can go a long way
Documentation is key
Versioning is a big topic
Make decisions
Processes, design, coding, etc.
71
Thank you Maayan for the warm welcome,
Hello everyone, and welcome to my talk about public API’s
My name is Amir Zuker, and let’s get going
Let's say we're a book store company
Fancy Books!
We sell books, but have additional cool features
We augment books, add narration and visualizations, and we integrate ML/AI processes and pipelines to make it happen.
MVP - We need to build a simple system, webapp + backend
We go with a cloud-based system, because, well.. why not
Ok, so we have our backend, few deployable units, nice
Modular monolith, serverless, containerized workloads (macro/micro/nano svcs) – doesn’t matter
We need Web FE – CDN, Domain, browsers connected, cool
We add additional services to bind everything together..
Cool, now it works
New features and changes need to roll out
We change the code
We control the entire spectrum
Align everything to work
Sanity / smoke-test type of thing
New version of orders and exploration
Ship it!
Deploy everything together, all versions are aligned
Everything is deployed, all's good and aligned
Fancy books becomes increasingly popular!
Sales, marketing says they should expose some of the API's to consumers
Dev team: sure, we'll build a simple separate docs app and expose the URLs
Ok, it's documented to some extent, marketing can promote it and developers can start using it
So we have external customers use our API's
System to system, external FE clients, business customers, commercial/non commercial use, etc.
And then..
Sales, marketing – how do we know who use it? How can we manage subscriptions, license and bill?
How do we know how many use it? Where to invest? Analytics?
HA, SLA, Commit? How?
Dev – how do we manage changes? (b4 – sync both ends) Stability? Doc it and Communicate?
Security (attackers) – DDos, penetration – how can we handle that
No standards, hard to adopt
Support tickets and calls
Hard to move
(CLICK)
Next: extinguish fires
--
---
Now, all kinds of things start to surface
How do we license certain API's?
How do keep track of KPI's for billing information?
How do we monitor API for health?
How do we protect the API's and enforce policies?
New changes coming in, as usual, change the code and ship it
Breaking changes were introduced – not even intentionally nor was it communicated in any way
Docs app is outdated
SLA? HA? Maintenance procedures?
How do we communicate things?
How do we version things? Keep things stable? Short-term vs. long-term commit
How do we manage the R&D, procedures, pipelines, codebase and the solution as a whole to account for such things?
API's use non-consistent nor widely-accepted practices
Even within the same API's
Hackers try to penetrate our system, are we good?
Attackers try to bombard our API's, DDoS, are we good?
Support calls coming in at an alarming rate
Times goes towards extinguishing fires
Competitors provide similar services, better controlled, we're starting to lose customers
We go bankrupt and our company is terminated
Times goes towards extinguishing fires
Competitors provide similar services, better controlled
Customers leaves, We go bankrupt and our company is terminated
Senior software architect, instructor, speaker and developer
Over 20 years of experience in the field
Designed and developed various systems, both backend and frontend
Mentored and lead large teams and R&D divisions
Publications, e.g.
Book: HandsOn Full-Stack Web Development with ASP.NET Core
Open source: WCF Contrib
WCF Microsoft Official Curriculum (MOC)
Head of Web and Mobile at CodeValue
Every bullet can be a lecture by its own, so we’re going to touch only at the high-level
Over the wire
Skillset and expertiseTechnical aspects
Technological advantages and constraints
Offering, licensing and pricing
HTTP/3 – QUIC
Needs:
What you need to expose
Skillset and expertise
Technological advantages
Interoperability
Technical constraints
Offering, licensing and pricing
How much public is considered public?
Case study: B2B, inside the same RnD - operational system and automation workflows
Communication – deprecation notices, release roadmap, maintenance timetable
Portals – backoffice and consumer facing
In many aspects, a public API is different than an internal API
Compatibility and stability
Scalability
Concurrency
Security and validation
Rate limiting
Etc.
You need to meet SLA and contract, even in the long-term
Provide what is necessary, no more no less
Requirement – expose books catalog
Use-case – b2b system-to-system sync purposes
Catalog hardly changes, blob, API for current month only, slim unaggregated payloads, simple continuation-token paging, etc.
APIM – API Mgmt
https://dzone.com/articles/api-gateway-vs-service-mesh
https://blog.christianposta.com/microservices/do-i-need-an-api-gateway-if-i-have-a-service-mesh/
https://konghq.com/blog/the-difference-between-api-gateways-and-service-mesh
So things can be more complex.
We could have a graph of such components (APIM,Mesh)
(ANIM-CLICK)
Big R&D, Enterprise divisions, different needs of such components
Might lead to multi purpose components and several tools – ingress/horizontal-integration/BFF's
Some might be applicative, more towards OSS/DIY, while other could be more infrastructure – use tools/platforms
E.g., projects where we build CRD’s + controllers where divisions can spin up API-GW as a managed resource and leverage an existing solution we build for the organization
---
Mention Maayan's project
There’s Envoy (network proxy)
Istio is service mesh which is based on Envoy Proxy
There’s Gloo – fork of Envoy – adds enterprise-level features + support + nice convenient product
Based on k8s philosophy – give desired state, I’ll bring it there
K8s CRD (custom resource definition) – can extend and build your own resource – “API GW”
Invent schema for the resource definition, now we can create such resources
Need to implement a controller – listens to resource events (created, updated) – responsible to sync between current-desired
Maayan’s project took it further, created CRD for certificates, DNS Record, API-GW (gloo edge enterprise)
Every division can deploy API-GW as managed k8s resources with the same platform and stack
Diff integrations – system-to-system / FE
Underlying services can have a slice of the complete payload (esp. micro)
Consider BFF, BaaS
Can be more than just query, application-level logic, might require extensibility/DIY
Aggregations – book – author name along with the id
https://blog.hubspot.com/website/api-gateway
Many tools – make sure to evaluate against your needs
Type of integration
B2b, mutual auth - perhaps certs
Public, no identity identification – api keys is simple
Some SASS/OTS provide key mgmt
Code first
Maintained by developers
Implementation is the source of truth
Contract first
Maintained by relevant people
Contract (spec) is the source of truth
Middle ground – spec can be coded
e.g., RAML or just code
Developers implement the application requirements directly
There is no contract or specification at first.
Requires a strong communication between the teams implementing application parts.
If the delivery time matters, a small or an internal API needed to be developed, Code First approach can be the convenient one.
Also, a specification or a documentation can be written later for the consumers of the API.
Slow feedback loops – Your feedback loop from “start design” to “get feedback” is measured in days or weeks. Even if you adopt a multi-phased implementation approach where you leave rigorous testing until after the initial API design is approved, chances are you’re still going to be implementing a bunch of code before you can get anything up for review. If you need to get feedback from external customers this feedback loop is further extended with deployment cycles etc.
Context is spread across multiple places – When you open a pull request, there is no easy way to separate out the API design from the implementation details, and reviewers need to keep the overall API shape in their head as they review multiple source files.
Low-value review feedback – Related to #2, review feedback tends to end up being less about the API design and more about implementation details (“I think this should be moved to a separate class,” “Could we introduce some composition here to improve re-use,” etc.). While this is great for the implementation quality, it distracts from the goal of getting a solid API design.
Frameworks leak into the design – This is my pet peeve. I often see framework concerns leaking into API design because it makes implementation easier, rather than because it makes the resulting API better. I object to having my frameworks dictate how my API behaves. How many times have you seen comments like “I did it this way because otherwise, I would need a custom Jackson de-serializer“?
Your API spec is limited by the available tooling – Many Swagger generators don’t have full spec coverage and it can be painful to coerce them into generating the spec you want. We have had a lot of trouble in Java-land trying to get rid of readOnly flags (why should we break our immutable data model just to make the spec generation happy???) and to be able to specify the maximum number of items in an array (you just can’t do it with the current Swagger annotations).
Include in review processes
Incorporate in DevOps pipelines
Next: One of the leading versioning practice is.. Semantic versioning
There’s more – dash (release,hotfix), plus (meta)
Behavior – input validation – throw on unexpected fields (removing optional is breaking) / SLA – performance changed
Spec mixed – minor – query string / major – host – both in url
Decision factor – http caching
Media –
Many REST advocates prefer media type versioning as it solves the "one resource, one URI" problem cleanly, and allows adding versioning support after-the-fact. The primary argument against it is the fact that the version is not visible when looking at the URI
When we version the Media Type and extend the language, we go through Content Negotiation based on this header. The REST API would make use of custom vendor MIME media types instead of generic media types such as application/json. We're going to version these media types instead of the URIs.
What's important to understand here is that the client makes no assumptions about the structure of the response beyond what's defined in the media type.
This is why generic media types are not ideal. These do not provide enough semantic information and force the client to use require additional hints to process the actual representation of the resource.
Let’s talk about different approaches and aspects that can drive how we design our api's
Innovative – author new ways of doing things
Conventional – use industry-founded practices
Be conventional if it serves the needs.
Look at what others are doing (e.g., advanced query)
For example, advanced query
Can look up to what other API’s are doing (google, Netflix, etc.)
Use widely accepted headers, status codes, etc.
REST is not a standard
We build RESTful services that adhere to REST principles by using HTTP
E.g. of non-RESTful - use-case driven RESTful api’s
The more innovative – better docs, more support, etc.
Generally – be conventional if it meets your needs
Rich – let’s expose everything / all functionality. Creates large api surfaces
Minimalistic – needs and usecases, commit only to what you need
For example – filter/sort – is it really needed?
---
Minimalistic – commit only to what you need
Meet specific use-cases
Flexible – all ways of doing things (REST, GQL, gRPC).Paging – skip + top / pageIndex + pageSize / continuation tokens
Opinionated - Tunnel clients for specific usage patterns
Clear – be informative vs. Vague – not to into details
E.g., creating a book – email the author.
Can be runtime too – validation errors
Be clear where it serves a value
---
In some areas you may choose to be clear and informative while in others ambiguous
If you say something, you commit
What do you include in the docs?
E.g., idempotence keys
This relates to errors and runtime as well
Validation errors – do you provide info or not?
Performance-oriented API’s can affect the API and make it more complicated
Or perhaps it’s not really needed and you’ll decide to keep things simple
Performance –Large json / string / blob, claim checks, chunky vs. chatty, include/expand, etc.
---
Factor API’s performance-oriented only when it serves a real purpose
Internally, how much freedom do you want to give developers and others?
Strict codebase, conventions, workflows
--
Permissive - Developers model the API in a way convenient to them
Stable – on what you decided to commit to
Consistent – within your API’s and industry-accepted practices (if it meets your needs)
Symmetric – within your API’s, naming, formats, etc. (Book.bookId / User.id / dates)
Implementation details – e.g., enums (deleted) and hash functions, etags, continuation tokens (can be opaque)
Let’s talk about different criteria that can drive our design philosophy
Opinionated - Tunnel clients for specific usage patterns
Informative – docs, error responses
Compatibility – expansion over breakage, Try to design in a way which accounts for the roadmap
Unstable
Commit for version only
X months
Changes in the app ripple through the API
Announce breaking changes regularly
Work with 3rd party to adapt frequently
Rich
Expose everything clients may want
Large API surface
Unopinionated
Let clients act upon their will
Just HTTP
Developers model the API in a way convenient to them
We see the APIM lifecycle
Every round can be an entire world of tools, technologies and workflows
Agility first - Fast delivery, short iterations, minimal specs, quick feedback
Diff. lengths
---
Gain confidence
Like any other product
Alright, that's a wrap!
Next, resources!
Alright, that's a wrap!
Thank you all for listening, I had a blast
Enjoy the rest of the conference, and happy coding