Most APIs work fine until they meet production. Then the cracks show: retries that amplify failures, latency that compounds across services, a downstream outage that takes everything down with it.
This two-day, hands-on workshop is about building APIs that hold up under real conditions. You'll start with a single REST service, evolve it to gRPC, then to a message-driven architecture using RabbitMQ. Along the way, you'll work through the patterns that production demands: versioning, observability, resilience, Outbox, Sagas, Competing Consumers, and more.

# Workshop Structure & Contents

- Why API design matters
- How we address the NFRs

## Introduction to API design

We will cover

- Guiding principles for API design
- Modular design
- What makes a good API

## Designing REST-based APIs

In this section, we delve into the intricacies of REST-based APIs, their client/server nature, and the decision-making process behind choosing REST, offering a detailed guide to the API design process, documentation, and the most common usage scenarios.

- Http methods
- HTTP status codes
- HTTP headers
- Endpoint naming
- Media-type selection, design & custom media types

## Designing gRPC APIs

In this section, we cover gRPC, and we outline the RPC API design process. We start by exposing and defining operations, particularities of consuming these APIs, and documenting them. This succinctly summarizes the key components covered in this part, providing an overview of the gRPC protocol, considerations for RPC, and the step-by-step process for designing RPC APIs.

## Messaging-based APIs

In this section, we take our previously designed API and start making the necessary changes to make use of asynchronous messaging.

We deep dive into a new world that covers queues, topics, message brokers, different abstractions and patterns, and we will see what changes are needed to adapt our previous architecture.

In this section we will see how we can introduce patterns like Outbox, Competing consumers, Sagas, and learn what we gain from using them, as well as looking at how we can monitor our system.

## Addressing non-functional requirements:

- Versioning strategies for backward and forward compatibility
- Observability
- Reliability
- Error Handling
- Fault tolerance
- Resilience tactics
- Documenting the API
- Why document, and why is it important
- Performance, Optimization, and Scalability
- Throttling
- Measuring performance
- Compression and caching types
- Rate limiting
- Caching & Conditional caching

Prerequisite

This is a Bring Your Own Device (BYOD) workshop. Therefore, attendees are required to bring their own device with the necessary software already installed:

- Need to have Visual Studio, or an IDE you are familiar with
- .NET 9 or higher
- Docker
- Github
- RabbitMq installed as a standalone instance, or we will install it in Docker

Who should attend?

- The workshop targets .NET Software developers who want to have a more architecture-focused approach
- C# developers who want to understand the communication patterns and the best practices for APIs in distributed architectures.

**At the end of this workshop, you will be able to:**

- understand which APIs are best suited for which scenarios
- understand what the non-functional requirements are for a production-ready APIs
- Evolve a ‘traditional’ architecture to a more complex one that uses asynchronous messaging
- Understand what asynchronous messaging brings to the table and where it can benefit our distributed systems