Saving State in a Web Service
Web services, by their very natures, are stateless, and this is no different to any other web application with a frontend. Its often helpful to keep track of the sequence of events something experiences. Similarly we might want to store the details a particular piece of data encounters on its lifetime in the system. When it was created, when it was changed, where in a given process it is up to, and so on.
A good example of this is a service I run for a few friends which accepts a URL, requests it and takes a screenshot, then turns that into a thumbnail and makes it available. There’s a few definite states in that sequence and its better to store which it is than try to guess from which fields have dates in or something. So the states are something like “new”, “error”, “in progress”, “ready” and “expired”. I can look at any of the jobs that come in, at any time, and know exactly where that item is up to.
When Things Go Wrong
It’s also pretty to have a strategy for failure. I already talked about giving users sensible feedback from a service, but the service also needs to keep track of what’s happening. There are decisions to make which depend entirely on the application under consideration but for example whether a failure is terminal, or whether the system should keep trying is quite an important thing to consider. Perhaps you just want to flag records that failed, so you can check on them later. Or you might want to retry – a set number of times? Or at decreasing intervals? An undesirable outcome would be to have the same record submitted every minute (or whatever) forever, so its worth planning to avoid this eventuality. Think also about the likely causes for failure – a split-second glitch or a likely human error which might take a day or two to be noticed and rectified?
Logging is something which is ideally of zero value. If nothing ever went wrong, you’d never care to look at an individual record and dig into its journey. However in the real world, we do need to be able to debug systems, sometimes under pressure. With logging there are a few different choices – whether to log to file or database, and whether to log continuously, or only at given times. Times when you might want to enable or increase logging are in development and when tracing a bug. However having some background amount of logging (and a way to stop the archives becoming too large) is recommended to keep track of who did what and when. Bear it in mind for a service just as you would for a web application.
I consider your advice for making strategies for failure as most wise. I do consider though that this is the hardest thing to do when you are building something. It is almost like not wanting to allow yourself to think that something could or even will go wrong.
Allan: Just remember that users are idiots! Of course users are not idiots but like most of us they may accidentally typo or input incorrect information – how we deal with those situations and help direct the user to the path we intended is really key. This is true for services and of course the wider web.
This is a mini series on points to consider when designing and building web services. So far there have been posts on error feedback for web services, auth mechanisms for web servicesand saving state in web services. When designing a service API, ther
This the last entry in a mini series on points to consider when designing and building web services. So far there have been posts on error feedback for web services, auth mechanisms for web services, saving state in web services and using version paramet
Over the summer months I wrote a series of posts about designing APIs in general, and web services in particular. This included posts on status codes for web services, error feedback for web services, auth mechanisms for web services, saving state in web