Introduction

This documentation refers to version 1.1 of the Five Minute Chat service.

The aim of this document is to describe the API in terms of expected behaviors and the few well-defined flows. Additionally, some of the inherent and/or configurable behaviors of the system are descibed so that developers can easier understand how to best approach their specific use-case.

Definitions

The API message models are split into three (3) main groups of types. The first two are messages, where naming depends on how they are used, normally in the format <Source>[Action]<Domain>[Type].cs

• There are two possible sources: Client and Server.
• Action is optional and is normally something akin to a CRUD operation (Create, Read/Get, Update, Delete) or empty
• Domain is whatever the message is about (as in subject)
• Type is optional and is either Request,Response, or empty

Examples: ClientCreateSupportTicketRequest and ClientChatMessage

The third is a group of models which are part of messages and are merely named according to the data they represent. Objects of these types are never sent by themselves without another object enveloping them.

Example: UserInfo (containing information about a user)

Standard flows

Most flows in this API are fire-and-forget or single request-response flows.

Examples:

• ClientChatMessage is sent by the client every time the user wants to send a message to a channel. No immediate response is expected as part of the flow (fire-and-forget), but the client will receive a ServerChatMessage as a direct consequence of the initial request. The fact that it is not a request-response pattern is from an architectural perspective an important distinction, but from the point of view of the individual application, it's really the same thing.
• When the application sends a ClientJoinChannelRequest it should expected to always receive a ServerJoinChannelResponse back with the result of the operation

Having said that, there are also a few flows that are a bit more

The login handshake

In the case of initial login to the servers, the client is expected to follow a protocol in order to establish the connection correctly. It differs slightly between different types of transport, as a raw TCP connection must first establish an encrypted communication channel before sending any sensitive information to the server while a HTTPS connection such as (SignalR) already has an encrypted channel to communicate over.

This protocol is described in the following diagram:

Support ticket fetching

As opposed to getting the history of a chat channel, or private messages (whispers), support tickets are handled differently. Instead of returning the contents of a request for support ticket information immediately, only a status (whether the request was successfully processed) is returned. After that, messages in the ticket thread will be sent in the same fashion as they were sent under the original session.