🧵Have session types ever been fully reified for web services? I'm thinking of something like HATEOAS, except the client begins by either fetching a server's supported session type for all its APIs or using a locally cached copy of that type.
When the client sends the first message it also sends that session type sans the first part corresponding to that message. The server can evaluate whether the provided session type and initial input are still supported and either progress or notify the client of the change.
Furthermore, the server can use the session type to guide and validate its response. The response can also include the session type sans that message. The client, in turn can do the same.
They just go back and forth until the session type reduces to a valid end state or when one of them misbehaves or times out, in which case the session (and perhaps its effects) are rolled back.
Embedding the permissible communication flows within each message makes protocols self-descriptive and therefore much simpler to validate, version, and introspect.
HATEOAS enables us to write a generic client that interactively offers follow-up options to the user after each response from the server.
What I'm talking about would let us write a generic client that, given a session type and before talking to the server, simulates all possible sessions. The user can interactively program a specialized client. As long as the server supports that session type it should just work.
You can follow @mx00s.
Tip: mention @twtextapp on a Twitter thread with the keyword “unroll” to get a link to it.

Latest Threads Unrolled: