Jul 11
21
While our web development team have been beavering away on the new optimisation process in the website (which, I’m sure you’ll agree, is looking fantastic), I’ve been quietly busying myself with some major new upgrades to the back end.
Although the bulk of our customers choose to use the website interface on routeoptimiser.com, some of our larger customers prefer to integrate our technology into their own systems. We call this suite of web services our “API”, and this is what I’ve been working on improving for the last few months.
Feature Overload
My original optimisation web service, several years ago, was very simple – you gave the web service a start and an end postcode, a list of delivery postcodes, and a few seconds later the web service returned out your optimised route. Over time, I’ve added more features: timeslots, vehicle capacities, waypoint pause times, vehicle dimensions, driver breaks and speed profiles. Currently in beta, we have yet more features: variable vehicles, maximum day lengths and waypoint priorities. All this is adding to the complexity of the original web service, and it’s starting to show.
But perhaps the most radical new feature that’s currently in Beta is the Insert method, which allows you to insert a new waypoint into an already-optimised route without re-doing the entire optimisation. This is very useful for people that have last-minute deliveries or collections to make, after they’ve already planned and/or started their route.
This insert method is, however, starting to highlight a growing problem with the current API model. The API is, essentially, stateless – that is, you give it some input, we give you the output, then we forget about it. If you want to do anything else with the results, you (the programmer) have to remember them yourself. To do something like an Insert, you have to tell us not only the details of the new waypoint, but also the full input that you originally put into the Optimise method, as well as the original output you got from the Optimise method. It turns out, that’s 43 separate input variables, many of which are arrays of values. Clearly, this is not very efficient, pretty confusing, and prone to subtle user errors.
New Model API
Today I’ve released a set of 12 new optimisation web services, designed around a different philosophy. These services are designed to remember the state of your optimisation jobs by storing the information in our databases. You start off by calling the Create method to create an empty optimisation job, and this gives you a unique JobID. You can then pass this JobID into any of the other services to do things like adding waypoints and vehicles, tweaking the job parameters, reviewing the input, checking the status of the optimisation (in progress, complete, etc.). There’s a service to start the optimisation, one to get the results and some for getting turn-by-turn directions and polylines.
An added benefit is that by splitting up the StartOptimisation and GetResults web services, this eliminates the timeout issues that some people were getting with the old Optimise web service, which for a very large job, could take several minutes to complete.
Future Plans
These 12 services are just the start of a series of API improvements scheduled for the coming months. Phase two will be to create services to generate the PDFs and SatNav itinerary files that you see on the website, and then to tie the routeoptimiser.com website in to use the new API. With this convergence complete, you’ll be able to create a job using the API and view the results by logging into the website, and vice versa.
Phase three will be the addition of some really neat new services that will allow you to edit a route after completion. You’ll be able to add, delete and move waypoints around, reverse a single route and create a new job based on the input of an old job. This will replace the Insert method above (removing the need for 43 input parameters).
The fourth phase we have pencilled in is the inclusion of features to support vehicle and parcel tracking. You’ll be able to call a web service periodically to tell us where your vehicles currently are, and then retrieve accurate updated ETA information for later waypoints. You could then choose to use this information to keep your customers better informed.
I hope you’ll agree that this new way of optimising will be much neater and clearer for programmers to use, and I look forward to completing the rest of it. If you want to have a play with the new API, currently in Beta, please create an account and then check out the API documentation. If you have any questions, get in touch!
Posted in Updates by 
I’ve just added five more web services to the new API, so you can now generate PDFs and query the cost of a route. I’ve also included the old VerifyLocation web service for convenience. This takes the total number of web services in the Beta API to 18.
Rich.
Phase three is now complete. I’ve just added another 8 more services to the list for modifying routes that have already been completed. These include automatically (or manually) adding extra waypoints, moving or deleting waypoints and reversing entire routes. There’s also a new Copy method for creating brand new jobs similar to a previously-completed job.
Work on phase four (vehicle tracking) has now commenced!
Rich