Page History

...

The SRP HTTP Framework does not enforce statelessness nor does it offer any tools to make the system stateful. Statelessness is really a matter of self-governance in the design of the API. Developers can move toward statelessness by avoiding, or minimizing, database locks, and responding to resource requests . Resources can also be returned along with metadata (see Uniform Interface below) that instruct the client how it can request a state change. Stateless APIs are not difficult to implement unless they need to operate within the same application that requires a stateful design, such as one that also supports a traditional OpenInsight desktop share resources (i.e., database tables) with a desktop OpenInsight environment. In these cases, OpenInsight clients typically maintain pessimistic locks on database rows. Stateless APIs typically use optimistic locks (or no locks at all), which could create conflicts in the way a web API interacts with the same rowboth of which require a way to resolve conflicts if an OpenInsight client is retaining a lock for an extended period of time.

Uniform Interface

REST, as it is argued, attempts to use HTTP more faithfully. This is the primary basis for a uniform interface. That is, by adhering to the published HTTP standards, API producers and consumers can better anticipate how to interface with each other. It also provides for greater decoupling, allowing independent evolution between the client and the server.

...