LornaJane

The date for PHPNW was announced a few weeks ago as Saturday 10th October 2009, and now we've got all the official bits and bobs to go with it! In outline:

The website: http://conference.phpnw.org.uk

Tickets: http://conference.phpnw.org.uk/register. Early bird pricing until September 11th, student tickets available - look on the website for instructions on getting student tickets.

Call for Papers: http://conference.phpnw.org.uk/callforpapers. Speakers wanted! If you have something to share and you think you can do that coherently - then submit to us please, we're always looking for new people, new talks, as well as the talks and speakers you'd expect to see at the bigger PHP conferences. If you're not sure if something fits, feel free to contact us.

This is officially a one-day Saturday event, with a full day with two tracks of talks and an attendance of 200+ people. In reality its a whole weekend of geeking out in Manchester - with a pre-conference social on Friday night, the main event on Saturday, a conference social running on Saturday night and an informal set of sessions on Sunday morning for anyone with the energy to keep on going before everyone makes tracks to their homes.

If you're going, thinking of going, went last year, or wishing you could be there - add a comment! I'm looking forward to meeting many of you at the event :)

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 parameters with web services.

Unlike the other posts in this series, this one is quite specific to one type of service - REST - since it deals with status codes, specifically HTTP ones. The ideas are transferrable however and other types of service can return statuses in a similar way.

There's a few key things to think about when returning status codes. In earlier posts in this series these was discussion of using existing application framework to serve pages and changing the output mechanism accordingly. Usually a web page will return a status 200 for OK or also 302 for found, so this is fine when things are working normally. But when things aren't going quite so well, its useful to give alternative feedback that can be easily picked up by a client application.

When things go wrong there are a couple of different schools of thought of how the service should respond. One is that if, for example, the user supplies data which fails validation, the service could provide the OK response and a message to the user to let them know what needs validating - exactly as we'd return information messages to a user filling in a form. To be considered restful however, the service should more correctly return one of the "400" status codes, which means that the client made an error. Interesting and useful codes* in this series are:

• 401 Unauthorized


• 403 Forbidden


• 404 Not Found


• 405 Method Not Allowed


• 406 Not Acceptable


• 408 Request Timeout


• 417 Expectation Failed


• 418 I'm a teapot

* I didn't say they were both useful and interesting

Using descriptive status codes allows the client to get the headline of the problem without having to parse a whole request to find out whether it is good or not. HTTP already has this feature built-in, and so we make use of it (HTTP is pretty cool really, makes a great protocol for services!).

Where an error occurs on the server side - it is usual to return a 500 error or another in the 500 series. This lets the client know there is a problem outside of their control; it is useful to include information about whether the client should retry and when. Having a defined protocol for retries helps avoid the situation where a system comes back up only to fall over again with all the traffic from people retrying every minute (or other interval) - this is a real concern for systems that are under heavy load.

Status codes are like a headline to the calling entity about what happened, and are a valuable tool in the web service toolkit. For bonus points, leave me a comment and tell me which is your favourite status code :)

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 services and saving state in web services.

When designing a service API, there are lots of things you can do right, and plenty of pitfalls. Most of both of these are completely specific to the situation you are designing for but I have one tip that has helped me out in a number of scenarios: Include a version parameter with every method call.

This is invaluable, not just in development where you can increment when you change the API (which could be quite often!) but also in production. For example if you want to extend or alter an existing service, you can identify which version of the API the client thinks it is accessing and behave accordingly - either letting them know there's a new version, or preserving previous behaviours. Its never ideal to change the API of an existing service but sometimes it makes more sense to do so, especially if its just to include an additional parameter or something else quite minor, but which does cause an API change.

When you publish your shiny new service which does everything you need (including the hoovering), it might seem a bit redundant to require a field which is always set to the string "1.0" ... but in 18 months time, you'll be patting yourself on the back.

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 and auth mechanisms for web services.

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

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.

Today techportal published a new article of mine on their site - New Memcached Extension for PHP. Its a sequel to the article I wrote for them earlier in the year entitled Getting Started with Memcache. At the same time I wrote that first article, Andrei Zmievski released a new extension for PHP to make use of the functionality in the libmemcached library - so I wrote the new article to give some information about it.

I migrated this blog to serendipity almost two years ago, and there have been a few things about it which have always driven me a bit mad. Many of these improved when I upgraded to version 1.4.1 of s9y but a few have persisted, including having two of my sidebar categories not display correctly. Where most of the categories behave as expected, two of of them just didn't apply any filter at all and all my posts were visible on these pages.

I finally sat down today to diagnose the problem and discovered I was missing a record from the serendipity_permalinks table which was stopping s9y from being able to look up the id of the category. It was my craft category which is id 7 - all I had to do was run the following against mysql:


So now my craft category works fine. If anyone knows how to stop my feeds from showing old articles as new when I edit them but don't update the publication date, I'd be grateful! A bunch of imported posts are still missing their images, would be nice to be able to fix these without polluting my feed.