Before reading this: This is not a question about "Is SignalR better than REST?"

Imagine creating a new API project using .Net 5 or 6 I see many projects providing a REST API to

• query data via GET
• write data via POST

and SignalR hubs to notifiy the clients about changes in realtime.

Based on the docs sample for 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);
    }
}

clients can call actions on the server that might write data to a database. So I could replace the REST POST endpoints with hub actions.

Based on the docs sample for communication

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

I could also ask for data, e.g.

public Task CallerRequestedAllMessages()
{
    Message[] allMessages = database.ReadAllMessages(); // pseudo code

    return Clients.Caller.SendAsync("ReceiveMessages", allMessages);
}

and replace the REST GET requests.

Are there any technical reasons to keep the REST API? Of course I can't consume the API directly like so

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

but that shouldn't matter when creating a "real" client connecting to the hubs and it seems people are working on packages for autogenerated SignalR API documentations.

Is there anything a .Net 6 REST API project provides or solves that a SignalR project can't?