You're reading from Web API Development with ASP.NET Core 8

Product type Book

Published in Apr 2024

Publisher Packt

ISBN-13 9781804610954

Pages 804 pages

Edition 1st Edition

Languages

Concepts

Web Services

Author (1):

Xiaodi Yan

Table of Contents (20) Chapters

Preface

1. Chapter 1: Fundamentals of Web APIs

2. Chapter 2: Getting Started with ASP.NET Core Web APIs

3. Chapter 3: ASP.NET Core Fundamentals (Part 1)

4. Chapter 4: ASP.NET Core Fundamentals (Part 2)

5. Chapter 5: Data Access in ASP.NET Core (Part 1: Entity Framework Core Fundamentals)

6. Chapter 6: Data Access in ASP.NET Core (Part 2 – Entity Relationships)

7. Chapter 7: Data Access in ASP.NET Core (Part 3: Tips)

8. Chapter 8: Security and Identity in ASP.NET Core

9. Chapter 9: Testing in ASP.NET Core (Part 1 – Unit Testing)

10. Chapter 10: Testing in ASP.NET Core (Part 2 – Integration Testing)

11. Chapter 11: Getting Started with gRPC

12. Chapter 12: Getting Started with GraphQL

13. Chapter 13: Getting Started with SignalR

14. Chapter 14: CI/CD for ASP.NET Core Using Azure Pipelines and GitHub Actions

15. Chapter 15: ASP.NET Core Web API Common Practices

16. Chapter 16: Error Handling, Monitoring, and Observability

17. Chapter 17: Cloud-Native Patterns

18. Index

Why subscribe?

19. Other Books You May Enjoy

Real-time APIs

We have introduced some web API styles, such as REST-based APIs, gRPC APIs, and GraphQL APIs. They all follow the request/response pattern – the client sends a request to the server, and the server returns a response. This pattern is easy to understand. However, this pattern may not be suitable for some scenarios.

Let’s say we have an application that contains two parts – the server, which is a fire station, and the clients, which are the fire engines. How can we notify the fire engines when an incident occurs?

If we use the request/response pattern, the clients need to send requests to the server to get the latest notification regarding the incident. But what is the best frequency of sending requests? 1 minute, or 10 seconds? Think about how urgent the incident is. If the fire engine gets a notification after a 10-second delay, this might be a problem, as the fire might be more serious and urgent! So, what about sending requests every 1 second...