Scoped and Persistent Connections 

Let us take a look at an example where we use both stateful and stateless APIs. We use the example of a terminal console. In a stateless API, the console takes one command at a time and returns the output. There is no state maintained between the previous command and the current command. So if we wanted to list the files of a directory by changing to that directory, then we do it all at once in a single command otherwise we don’t do it. In a stateful API, we do processing of the command but maintain the state so we can issue one command for change directory and another command for listing the files. 

One way to mimic the stateful API over the stateless API would be to replay the history of commands. If there is only one command, we execute it. If there is second command we look up the history to find the earlier commands, execute it and then execute the given command. If we tolerate the performance, we can use this method, however this assumes the commands are idempotent which means they can be called repeatedly to the same effect. 

Generally the APIs are never interchanged since they serve different purposes. But one can be used over the other. In this case, we take the example of a state represented by a connection and use the stateless calls over these for the commands. The only difference is the connection has a setup and teardown and we persist for the duration of the calls. This is very similar to socket and in fact many networking protocols have a setup and tear down phase. 

The commands coming over the stateless APIs are decoupled from the stateful connection setup and tear down that maintains a single connection over which all the commands are run and the output returned through the stateless APIs.  

Here the state is maintained for the resource. In some cases, the state is maintained for the user. In such a case the order is reversed. The stateful layer is over the stateless APIs. This is exactly the case for many portals where the user session needs to be tracked so that the users have a seamless experience between the actions they take and they don’t need to repeat their authentication each time. 

Such state have a lifetime and this is established beforehand or tied to user actions. In all these cases, the destruction of the state invalidates subsequent api calls and this is very much like the socket that is terminated so that no subsequent actions can be taken.  Generally the state is referred to with a key or an identifier that is used by the subsequent API calls.  

#codingexercise 

given four keys letter A, ctrl A, ctrl C, ctrl  V find the maximum number of A we can print using the combination of keys in N keystrokes.  the elements of repetitions  are 
A
Ctrl V 
Ctrl V Ctrl V 
Ctrl A Ctrl C Ctrl V  
Therefore, one way to do this could be :

        static int getCount(int N, int copy, int current) 

        {

            if(N <=0)  

                return 0; 

            if (N <= 6) 

                return N; 

            int count0 = current+getCount(N-3, current, current * 2); // ctrl A+C+V 

            int count1 =  copy * 2 + getCount(N-2, copy, current + copy * 2); // ctrl V + ctrl V 

            int count2 = copy + getCount(N-1, copy, current+copy); // ctrl V 

            int count3 = 1 + getCount( N-1, copy, current+1); 

            var counts = new List<int>(){ count0, count1, count2, count3 };

            int max = counts.Max(); 

            return current + max; 

        }

            Console.WriteLine("Max = {0}", getCount(6, 0, 0));

            Console.WriteLine("Max = {0}", getCount(9, 0, 0));

            Max = 6

            Max = 12

we can also consider a variation of the above dynamic programming with varying length repetitions of CtrlV and CtrlACV at any position beyond 6th occurrence of A.