I have 14 years of professional software engineering experience contributing to companies ranging from startups to large enterprises.

About a decade of the experience has been dedicated to creating RESTful APIs.

I have faced several challenges over the year:

1. Coaching teams on the REST API conventions and why having a clean and consistent API design is important.

2. Collaborating on the API designs - creating sustainable engineering practices to design and develop the API specs

3. Validating that the API developed meets the API specs

Designing APIs

1. Having a good user experience and frictionless collaboration is more important than process compliance.

2. 

Testing

1. There is modern tooling available to validate the API spec compliance for the implementation. Dev teams should leverage these.

2. Good unit tests can do wonders for API development. More so since the advent of microservices.

3. Having tighter feedback loops are essential for Agile teams

I would love to discuss the challenges that I have faced at work related to API Design and testing with the practitioners present at the conference.

I plan to contribute by actively engaging with both the speakers during the sessions and the participants during the break-out sessions.

I have been designing and building APIs for more than a 15 years. Over these years I have extensively worked on

• REST Http, SOAP, etc.
• Internal and Public facing APIs
• API auth and auth, metering and monetisation, testing, performance engineering and security
• API Specifications - OpenAPI, AsyncAPI, WSDL, etc.

I am currently exploring developments in areas such as Server Sent Events, GraphQL, API Specification Standards such as AsyncAPI, etc.

My recent work involves leveraging API Specifications such as OpenAPI, as executable contracts to eliminate integration testing through Contract Driven Development. I am a core contributor to an open source tool called Specmatic that embodies this approach.

Independent development and deployment of services - Having a good API boundary should allow independent development of API provider / service and consumer applications. However, without proper mechanisms to enforce the API boundaries, integration issues wreak havoc in the later stages of development. So many teams resort to sequential style (Provider before Consumer etc.) which is not productive and severely impacts time to market while shipping features.

Stale Stubs - It is common practise to standup a mock server to emulate an API in order to allow convenience of consumer application development. However such mocks often go out of sync with the actual implementation. This again leads to broken integration late in the cycle.

Testing Providers - Providers do not have any emulation of the Consumer in lower environments. The only way to actually test if Consumers are compatible with a Provider seems to be either through Integration Testing and / or End to End Testing. This is a major setback for teams that have been adopting microservices since it impacts their ability to deploy services independently. There is a necessity to be able to shift left the identification of compatibility issues and reduce / remove dependency on Integration Testing.

Communication and Collaboration - API Designs being communicated over textual / non standard / non machine readable documentation is / has been a major contributor to communication gaps between developers. Adopting machine readable specification standards such as OpenAPI is a welcome change. However there is a necessity to start treating these API Specifications as code in order to effectively collaborate over them.

Backward Compatibility - As APIs evolve as we add capabilities, testing for backward compatibility is both expensive and time consuming. Adding features becomes progressively more difficult as we have take into account all the possible impact areas.

API design cannot be an afterthought - Be it internal, backend for front end, public facing APIs, it is important in my opinion to begin with the API Design. This has several benefits such as fleshing out the use cases, reaching an agreement between stakeholders, etc. ahead of time. However this does not mean complete upfront design that is set in stone. Initial broad strokes design leaving room for API evolution has been definitely productive in my experience.

API Specifications as Code - I have been leveraging OpenAPI extensively and we treat API specs as code, meaning they reside in our version control. Changes go through a stringent pull request based process just like any other code. This allows for a single source of truth for all stakeholders (Designers, Architects, Developers, Testers, etc.).

API Specifications as Executable Contracts - It is important to enforce API Specifications so that both API Clients and Providers are adhering to the design that was jointly agreed upon. This needs to happen early in the development cycle to avoid integration issues later in the cycle.

API Design Patterns and Reuse - Patterns naturally merge within the context of each industry verticals and organisations. It is a good idea to remain consistent with an overall agreed pattern on how a certain feature behaves (Example: pagination, filtering, etc.). Capturing such patterns as reusable API Specification snippets reduces duplication and promotes consistency through reuse.

API Design Style and Smells - Linting API Specifications is a great way to reduce burden on API reviewers by codifying practices. This can also reduce design smells.

At a high level, I would like to learn about how other participants have been tackling the integration testing hell with API boundaries and also their experience adopting specification standards such as OpenAPI. Below are some specific areas that I would like to explore

Should API specifications such as OpenAPI evolve to capture API behaviour in addition to capability. Example: OpenAPI 3.x allows us to describe all the possible response codes, however it does not have an inbuilt mechanism to document which request may trigger a certain response code. This means that for this part of the information, we need to either go back to looking at the API Tests, Workflow Tests or worse textual descriptions within the specification which is not verifiable / testable and hence has the risk of going stale.

Asynchronous APIs - Testing strategies and associated challenges

I would like to have / facilitate a discussion around one or more of below areas

API Specifications as Executable Contracts - What it takes to enforce API Specifications during application development

Async API Testing Strategies and associated challenges in test data setup, testing environment, etc.

Capturing API behaviour in addition capabilities with OpenAPI extensions, overlays, or are there other techniques?

Involved in designing and implementing APIs for over 10+ years. My domain expertise is in Messaging & Event-Driven Architecture. In this domain, over and above the classic REST APIs, we have been promoting asynchronous APIs, aka Event APIs, with a new standard called AsyncAPI. I am passionate about Event-driven APIs and see how they can evolve alongside synchronous APIs and standards. I am part of the CTO team that works extensively on AsyncAPI and our Event API products that we will roll out in the coming months.

Somewhat specific to EDA - the following or some of the topics that are crucial and challenging in consuming/testing asynchronous APIs.

- Schema versioning, validation, and management

- Server-side vs Client-side responsibilities 

- Message exchange patterns 

- Observability

- Support for Open Protocols & Standards

Interestingly, it is a complex activity in the EDA context - especially with the need to support different protocols (MQTT, AMQP, JMS, WS, and others), frameworks (NodeJS, Spring Cloud Stream), iPaas (MuleSoft, Booming, and others) and various languages. 

AsyncAPI & CloudEvents has made Event-driven API design and testing somewhat easy.

Learn from the API experts in this focused group and exchange ideas.

A talk, presentation, or workshop, whatever is appropriate with the organizers' approval. But, most likely as an observer and learner - look forward to connecting with people and getting a grasp of the API landscape.

I have experience in designing and building the API test from a testing perspective. I have involved myself in the conversation where developers were designing and building APIs.

However, I have done a small POC from the perspective of self-learning how to build APIs https://github.com/TrishaChetani/SpringRestAPIApplication

I have faced the challenge that there is no clear requirement from the API perspective so that the tester could plan to test it better.

• Since the changes in APIs are not planned well, so there is formal communication across the team. It leads to rework in the team. For example, the front-end developer has to rewrite the code, and the tester has to rewrite the test. 
• The whole team collaboration is missing. Since the business is not aware and the focus shifts to how many user-impacted features are delivered. This leads to the situation inside the team growing more technical debt day by day. (For example, significant bigger request payloads, long response time, too much data or irrelevant data in response, no versioning, no SSL,  no clear error code or error message)
• Since there is no clear definition, it is easier for a developer to reject the bugs. This is also because most of the team is having a high-level strategy but not at each layer.

• I learnt the lesson that API and backend changes should be documented, communicated and planned well.
• Having API functioning better improves application usability, security, and performance which in turn brings more users and leads to bigger business.
• rapidly build clear and complete flows of API 

How different teams are approaching?

What are the challenges for the different teams and how they are overcoming them?

Network with people

• Techniques for mapping of API specification to test specification.
•  A strategy to tests so that most of the testing is covered in the lower layer and which in-turn makes your testing more targeted. For example, positive flow, and negative flow includes error codes, permissions, boundary values, and logical testing, contract-based testing. 
• Techniques for reporting and monitoring

I had tried to adobt OpenAPI spec in all the services where we exposed REST API. Over the last 2 years, I have also got experience in AsyncAPI and writing interfaces for the async services written using Kafka.

• Making sure the specification is matching with the service logic
• Validating the service logic based on the output and input data defined in the OpenAPI Spec
• Keeping REST Apis backward compatible and having an upgrade path
• Integration/Component tests involving REST Api
• Ensuring Async services can't go beyond the contract defined in the AsyncAPI

• Automated Systems in place to enforce the compatibility of logic with the OpenAPI spec are going to work much better than manual checks in code reviews
• Async API (even though internal) needs to be kept backward compatible to allow dependent services to upgrade to the latest version in a planned fashion.
• It is important to give proper upgrade paths to the users of the APIs

Experience of the participants in the challenges we faced

Challenges and solutions around API spec evolution

I'm a maintainer of Apache APSIX—the open source, cloud native API gateway. Formerly, I maintained two Cloud Native Computing Foundation projects.

Through my open source contributions, I have been helping people move to cloud native environments for the past three years.

APIs for cloud native environments are my key focus.

We are in a challenging transition phase to cloud native environments. The benefits of moving to cloud native architectures often shadow its costs in security, scalability, complexity, and monitoring.

As monoliths become microservices, direct client-to-APIs communication means exposing the APIs for each microservice. This means that the API developers need to add functionalities like authentication, rate limiting, traffic control, and monitoring to each microservice.

Moreover, making changes to the API, like splitting or combining services, puts a burden on the consumers, requiring them to update their client applications.

When moving to the cloud and when you split monoliths to microservices, it is beneficial to use an API gateway. An API gateway will centralize responsibilities including security, scalability, monitoring, and more, making it easy for the API developer to focus on core business needs.

I plan to explore more about the challenges faced by API developers in moving to the cloud and adopting a microservices architecture. 

I also want to explore how people see API gateways and whether they use them/are familiar with them.

I plan to share my work with Apache APISIX and help people trying to adopt API gateways. I will share some of the best practices in developing modern APIs based on our experience in working with top companies to help them handle large-scale traffic.

Not much experience with design and development but explored enough on how to test them manually or via automation tools. Had worked on implementing or adopting frameworks to ease down regression effort for api testing.

• Frequent contract changes and tackling them in API regression suites
• Error/exception message handling
• Test data utilisation, handling big json requests
• Quickly setup tests for perf usecase, load testing with repeating same usecase multiple times

• New trends in API test and latest tools to ease out CD/CI processes
• Concurrent or parallel suites execution strategies in case of CD/CI for multiple service

This will be first few open forum for me to contribute but will try to reach out to open source owners and contribute to achieve most helpful setup or usecase in terms of API automation

I have architected test automation frameworks and integrated the testing with the DevOps operating model to align & provide rapid feedback

• Continuous change in API contracts
• Delay in API development
• Dependency for front end testing
• Dependencies with third party service providers
• Security concerns arising with API architectural changes

1. Using open source tools to create your automation tests automatically
2. Build APIs using PACT and use them to mock the backend APIs & emulate against front end
3. Use Open API swagger-diff tool to analyze the API definition changes and update the existing tests
4. Create mocks to mimic third party responses
5. Use security testing with OWASP to anayze the security flaws

Discuss the common problems seen by the community during testing of API services and learn any share best practices to the problems faced 

Share implementations & derive testing strategies integrating different API test types

I have worked with organisations in web hosting and telecom, each having millions or 100s of millions of customers, whose products leverage a plethora of backend APIs.

I've seen challenges in two key areas: integration failures and API design (APIs not designed for backward compatibility, observability or ease of use)

The main lesson has been to shift left and get feedback as early as possible. There are interesting tools that can be used to get early feedback on both API design and integration failures, and these can be used to great effect.

I would like to see the kinds of challenges others have encountered when building APIs, in particular integration, and how they resolved them.

I plan to share some of the problems that my colleagues and I have faced faced and solutions that we have leveraged while helping / coaching API provider and consumer teams.

Deeper API Security - API Protection, we use Swagger files to create and write api spec according swagger API spec v3.0 and test using rapid api tool 

The challenges is  different compactibility of language bindings to use the attributes of api while consuming them 

Automated Testing using Rapid API some times doesn't meet security standards , Protection of API using WAAP and policies wrote in custom language rego standards 

how to overcome those via new standardization in microservices world via event driven approach 

Networking with peers to understand how they use those and pain pin points regarding those, how to overcome those in microservices world via event driven approach

Yes i need to contribute to standardization of API on security Frontend By using DevSecOps Approach