Mini Cooper UK order status codes

Published April 18, 2013 – 10:47 am

Categories: Programming

My mini cooper has just been ordered, because I am nosy I have found out the UK order status codes from Mini (and BMW for future reference).

0000 Cancelled
0037 Model or Feature Unavailable
0077 No Quota Available
0097qq No Current Event Allocated
0500 Cannot be Scheduled

1100 Scheduled
1200 Scheduled for Production
5000 Confirmed for Production
5050 Chassis Number Allocated
5055 Confirmed by Production Control

5100 Bodyshop Start
5190 Bodyshop Complete
5200 Paintshop Start
5270 Paintshop Complete
5300 Pre-Assembly Start
5400 Assembly Start
5500 Assembly Complete

6000 Transfer to Distribution
8200 Released to Carrier
9000 Departed Plant
9615/35/45 In Storage
9610/20/30/40/50/60 In Transit
9800 Arrived Dealer


Backbone model saving + slim framework

Published April 4, 2013 – 1:33 pm

Categories: Programming, Work for others

Me and the lovely @webdevstu have been doing lots of work with Slim framework and Backbone.js over the past couple of months. One of the issues we had today is saving Backbone.js models. When you call the save() method on a backbone model, rather than doing something so standard as actually complying to the http standard, they have decided to encode and send the data as a json string. Now this is actually a little bit of a pain to pickup in Slim. It has an existing bit of middleware available called “ContentTypes” which will decode the raw request body. However that puts it so you can access it as $request->getBody(); rather than in the $request->post(); variables.

The solution to this is to pop in a nice bit of middleware, so I whipped up a VERY quick and slightly dirty class for the purpose.

/**
 * JSON Input Middleware complies to the Slim Middleware interface and will decode the JSON request body passed
 * if backbone sends the data as request body rather than complying to the actual HTTP standard.
 * 
 * @author Thomas Gray 
 * @package ContentHandlers
 * @subpackage Middleware
 * @copyright RandomStorm Ltd
 * @lisence: GPLv2 (no later version)
 */
class JsonInput extends \Slim\Middleware
{
    public function call()
    {
        $app     = $this->getApplication();
        $request = $app->request();
        $body    = $request->getBody();

        $contentType = $request->getContentType();

        if($contentType === 'application/json')
        {
            $body = json_decode($body, true);

            if(is_array($body))
            {
                $_POST = array_merge($_POST, $body);
            }
        }

        $this->next->call();
    }
}

Feel free to use & re-use. Released under GPLv2 :)



Single or plural resources in REST api’s

Published March 12, 2013 – 2:08 pm

Categories: Programming

There is some argument out there as to wether you should use plural or singular words to represent resources within REST. This is an argument that I have come across many times, and one that to this day I cannot decide as to which side of the fence I sit on.

Before we get into some nitty gritty, let’s outline the problem we are talking about. Let’s take for example an restful interface for accessing logs.

Let’s say that we have an interface that will return a representation of a list of other resources that you can access, like for example log files for download.

An example interface of GET’s

/logs – Returns the names of all of the logs that you can access
/logs/{log-name} – Returns the log you specified in the log-name variable.
/logs/range?dateFrom={dateFrom}&dateTo={dateTo} – Returns a collection of logs within the specified date range.

So this example is made under the concept that the logs interface is plural rather than singular, and certainly in the case of the first item, it makes sense, you are returning multiple log resources rather than a single resource, so it should be pluralised. However the issue really comes into this when we start talking about the second interface. You are returning a single resource as represented by the log-name variable but you are accessing it via the plural logs rather than just /log/{log-name} which if you are receiving one logically makes more sense.

In a way I agree with the concept that applying a single logic to this is logical, however in practice I have found that if you are asking others to consume your resource and they are trying to do so automatically rather than by browsing through generated content, then they would expect the interface to remain consistent (as with all programming) rather than changing from single to plural.

But what about the other methods?

So obviously GET is not the only request type that you have available, granted it is the most commonly used, but still, we can’t ignore PUT, POST’s and DELETE’s now can we!

I think that even though POST, PUT and DELETE usually refer to single resources rather than multiple resources the interface should still remain consistent.

My two pence

I think if you are representing multiple resources that are available for further access (in the case of my logs example above) then you should have the entire interface as plural. Although there is something to be said for single resources, in terms of consistency it would be simpler to stick to one interface.



Older posts »