Antes de leer esto: Esta no es una pregunta sobre "¿Es SignalR mejor que REST?"

Imagine crear un nuevo proyecto de API utilizando .Net 5 o 6. Veo muchos proyectos que proporcionan una API REST para

• consultar datos a través de GET
• escribir datos a través de POST

y concentradores SignalR para notificar a los clientes sobre cambios en tiempo real.

Basado en la muestra de documentos para SignalR

https://docs.microsoft.com/en-us/aspnet/core/tutorials/signalr?view=aspnetcore-6.0&tabs=visual-studio#create-a-signalr-hub

 public class ChatHub : Hub { public async Task SendMessage(string user, string message) { await Clients.All.SendAsync("ReceiveMessage", user, message); } }

los clientes pueden invocar acciones en el servidor que podrían escribir datos en una base de datos. Entonces podría reemplazar los puntos finales REST POST con acciones de concentrador.

Basado en la muestra de documentos para la comunicación.

https://docs.microsoft.com/en-us/aspnet/core/signalr/hubs?view=aspnetcore-6.0#send-messages-to-clients

También podría pedir datos, por ejemplo

 public Task CallerRequestedAllMessages() { Message[] allMessages = database.ReadAllMessages(); // pseudo code return Clients.Caller.SendAsync("ReceiveMessages", allMessages); }

y reemplace las solicitudes REST GET .

¿Hay alguna razón técnica para mantener la API REST? Por supuesto, no puedo consumir la API directamente así

curl -X GET --header 'Accept: application/json' 'https://my-api.com/messages'

pero eso no debería importar cuando se crea un cliente "real" que se conecta a los concentradores y parece que las personas están trabajando en paquetes para documentaciones de API de SignalR generadas automáticamente.

¿Hay algo que un proyecto API REST de .Net 6 proporcione o resuelva que un proyecto SignalR no pueda?