A RESTful interface to things that have integral “sessions,”

Question

I'm just starting to try to understand the principles of REST design and struggle with the first example I'm trying to do.

Let's say that I want to make a REST API design for something like an SSH session. Ignoring security, logging in, etc., I assumed that there would be something like a URI / session URI, and I would initiate an SSH session by POSTing in / session, defining the connection information, hostname, username. This will cause the web server serving the REST API to start an SSH session on my behalf, assign it some kind of identifier, and return the URI / session / [id]. Then I could interact with this session with sub-resources of this URI. This is not a desperately good analogy to what I want to do, but it does have a significant point: trying to define an interface for something that has a “session” and whose state changes when I send things to resources inside it.

Now my problem is its scalability, but I can't think of anything better. It relies on the web server initiating the SSH connection to the host, and this connection must be supported by the web server (therefore it will be lost if the web server needs to be redesigned). It also associates my request with one web server - I could not, easily, have a farm of web servers that process API requests.

I could move the creation and maintenance of SSH connections to another server somewhere, but this only really moves the scalability issue. And in general, then I need to define an API for this server, and why not make it a REST API, in which case I just got a duplicate of the first, ad infinitum.

Now I can just look at it wrong, not being resourceful enough, but, in my opinion, here the “resource” is an SSH connection. My problem is that the resource is not something that is easily shared - it is what the web server creates and is essentially transient.

Are there any RESTful API API gurus that can help me move the best way? Please note that I really do not think it is really REST-specific - a significant design problem has arisen. I imagine that I have ever taken an approach to developing this as a web service on the basis that the tent for interacting with web services was not stateless.

Thanks.

[EDIT:] Another problem with this approach is the “leak” of “session” resources when clients do not explicitly delete them. The most reasonable solution I can come up with for this is to define some session property (possibly customizable at creation, possibly a fix) that determines the time during which you need to contact the session again before it is considered obsolete and deleted . The client will get access to this property (for example, / session [id] / keepalive or something else), which will return the timestamp, split it into two (make a good time interval halfway between time and then) and make sure that if nothing he will not “interrogate another,” the server, again turning to the same resource until this time. If this fails, the session will be restored. This is the very “RESTful” approach that I can think of, but would appreciate the more experienced RESTful thoughts.

Answer 1

Usually, in order to be able to declare something as a resource, it must either be stored in some kind of persistent storage, or it should be easily reproduced. As you say, a session is a rather transient thing to try to model as a resource. This is also what is usually associated with a single client. However, the resource is usually shared, which is one of the reasons it is provided with a public URI. All this to say that you are trying to insert a circular snap into a square hole.

Having said that, if you really want to do this, and you want to scale, I can imagine two possible ways. One of them is to initiate a session on a single database server. This will allow you to scale web servers. Depending on where most of the work is done, this may or may not have any value.

Another option is to use hypermedia so that you can use the web server as the initiator of the session, but you need to make sure that the host name of the web server is part of the session resource URI. REST clients should not make any assumptions about the URI and should always read them from previous answers. If you take advantage of this, you can distribute sessions to different web servers, and the client simply follows the URL to find the session, regardless of which web server it is on.

Answer 2

I think there are several REST issues here, some of which are related to the fact that you are basically trying to implement SSH through HTTP. Among the problems that I see:

(1) Client state management by server - if you do not save the current connection (which seems strange), you break the spirit without taking into account the REST state.

(2) Performing actions to redirect to “updates” in the connection , rather than actions on real resources. From what you are describing, it seems that the actions that occur on the established SSH connection will be modeled as UPDATE for the SSH connection if you use the connection itself as a resource.

Of course, no one will throw you in jail because of how you are REST-ify, but in general I agree that you are trying to establish a square anchor in a round hole.

Instead, I would like to ask myself why this should be REST-ified. SSH connections are well understood and can be made between the parties in different ways without inventing what you are describing. Actually, if you are thinking of writing a GUI-based web application for your task, it looks like you are trying to implement one of these solutions with a green screen over HTTP, which is never a happy ending, so I personally avoid this.