HTTP

For a long time we made a decision not to implement a half-duplex protocol in XSockets. However, over the last year we have been getting great feedback and pointers on the topic. So we finally added support for both full-duplex and half-duplex techniques in XSockets.

The support for HTTP will be added in a pre-release (5.2.0-beta, 2016 May). Although there is some work to come on the HTTP support we are very happy about what we got so far.

Limitations

At the time writing this (2016-05-26) the HTTP support covers:

• GET
• POST
• CORS

We choose to disable the following verbs for now:

• PUT
• DELETE
• PATCH

Limitations:

• Will always return application/json and requires content-type:application/json in the request.

How it works

This is what we feel is really nice about the implementation. Your methods for HTTP is the same as the methods you usually write in XSockets! The only difference is that you have to add a attribute to the method so that XSockets know what kind of request you allow (GET/POST).

Example

This simple controller allows you to execute HTTP GET requests to the Now() method.

public class TimeController : XSocketController
{
    [HttpGet]
    public DateTime Now()
    {
        return DateTime.Now;
    }
}

So, we can just use POSTMAN to try this out. We do a GET request to http://localhost:4502/time/now

In postman it look like:

The really, really cool thing is...

That since you are actually using a standard XSockets controller/method to do GET/POST you can use all the normal XSockets features even if the call is half-duplex.

So even though the call is made from a HTTP Client the server can dispatch information to full-duplex clients.

Consider this sample...

Below we have a simple chat that obviously will work great with full-duplex connections. However, we also have the HttpPost attribute added so that HTTP clients can POST a message to the full-duplex clients.

public class ChatController : XSocketController
{        
    [HttpPost]
    public async Task Message(ChatMessage message)
    {
        // send to all client connected to this controller
        await this.InvokeToAll(message,"message");            
    }
}
// Just the model...
public class ChatMessage
{
    public string UserName { get; set; }
    public string Message { get; set; }
}

So, I tested the sample with a simple html page using the chat-controller over websockets. Then I did a POST to the same method as the socket clients use. Notice that we passed in JSON matching the ChatMessage model, then POSTMAN got a 200 OK and that the REQUEST took 9ms.

So now you will be able to call your XSockets controllers from stuff like jQuery and other things that you usually use to communicate with WCF, WebAPI etc. ;) You can ofcourse also add webhooks from services like http://IFTTT.com

What about security?

Well, this is built in since the HTTP protocol utilizes the same pipeline as a normal socket client. So you can still decorate the controllers/methods with the Authorize attribute and authenticate clients the way you are used to.

The origin for CORS is controlled via the configuration in the same way the other transports are.