10 June, 2014 by Denise << programming >>

Idempotence, REST and Caching

What is Idempotence and 'safety'?

Idempotence means the result will never be changed, you can keep calling the method, but the response you get back will always be the same. It is possible that something is being changed on the server, but the result not changing is what defined something to be idempotent.

Safety is where the resource on the server is not changed in any way. Things might happen on the server, but the resource itself is not modified. Consequently, the result is never changed either.

The set of safe HTTP methods is a subset of the idempotent methods.

Idempotent HTTP methods

OPTIONS, GET, HEAD, PUT, DELETE

Safe HTTP methods

OPTIONS, GET, HEAD

Browser/Proxy/Gateway Caching

Caching of an HTTP response may occur in a number of different places - it could be within the browser itself, in a proxy server or on a gateway server (also known as a reverse proxy cache).

Caching can only occur for the safe HTTP methods OPTIONS, GET and HEAD. To prevent this (or to have control over it) we need to play with the HTTP response headers.

Cache Expiration (cache-control: max-age=n or expires)

Cache expiration headers will prevent the cache from making the same request until the cached version reaches its expiration time and becomes "stale". If both the cache-control and expires headers are set then on most modern systems the cache-control will take precendence.

Cache Validation (last-modified and etag)

These are called 'cache validator' headers because they are used to validate the freshness of the stored response in the cache, without requiring your backend system to generate or transmit the response body.

A 304 Not Modified will be returned if the currently cached response does not differ from the response values returned by the cache validator.

Combining cache expiration and validation

Cache expiration is checked first, then cache validation occurs if the cache entry has expired. If the cache entry hasn't expired, it will return a 200 OK response. If the cache entry has expired but the request is validated as still being fresh then a 304 Not Modified header is returned, and this 304 response will have updated expiration header info.

Resources
https://www.mnot.net/cache_docs/
http://tomayko.com/writings/things-caches-do
http://www.mobify.com/blog/beginners-guide-to-http-cache-headers/
http://www.peej.co.uk/articles/http-caching.html
https://redbot.org/ - for cache testing

06 March, 2014 by Denise << programming, thoughts >>

Programming and Curiosity

I came across a quote recently from the well known book 'Code Complete' by Steve McConnell which I really liked (emphasis my own):

"It's no sin to be a beginner or an intermediate. It's no sin to be a competent programmer instead of a leader. The sin is in how long you remain a beginner or intermediate after you know what you have to do to improve".

Always be learning and improving, and stay curious!

17 February, 2014 by Denise << programming, java >>

Boolean comparisons

Ever wondered why people code boolean checks in if statements differently?

Example 1

This is the kind of code that fails silently because true will always be assigned to hungry and will cause the if statement to be true and the conditional code will always execute.

boolean hungry = Utils.isHungry();
if (hungry = true) {
    /* this code will always be executed */
}

Example 2

There is no possibility of an accidental assignment here, and is probably the most readable code.

boolean hungry = Utils.isHungry();
if (hungry) {
    /* make some cookies */
}

Example 3

This is the kind of code I have seen before but wondered why the developer has reversed the comparison. This is a defensive programming style, such that if in the future another developer accidentally changes == to = then the code will not compile because true is not a variable and the value of hungry cannot be assigned to it.

boolean hungry = Utils.isHungry();
if (true == hungry) {
      /* make some cookies */
}

In my opinion Example 2 is the cleanest, but now I at least realise why other developers might choose to use the style of Example 3.

16 February, 2014 by Denise << java, general >>

Why 0xCAFEBABE?

I'm guessing I'll get asked this question a fair number of times and that there'll be confusion around why I called my blog 'cafebabe' - do I consider myself some sort of 'babe' who hangs out in cafes?!

Well, the answer is a lot more geeky than anything like that. In the Java programming language, Java classes are compiled into class files containing bytecode that's then executed by the JVM. The first four bytes in Java class files are marked by the magic hexadecimal number 0xCAFEBABE. This marker is simply an identifier for the class file format to prevent the JVM from loading files that are definitely not valid class files.

As to why 0xCAFEBABE was chosen to be the magic number for Java? This is best explained by James Gosling, creator of the Java programming language:

"We used to go to lunch at a place called St Michael's Alley. According to local legend, in the deep dark past, the Grateful Dead used to perform there before they made it big. It was a pretty funky place that was definitely a Grateful Dead Kinda Place. When Jerry died, they even put up a little Buddhist-esque shrine. When we used to go there, we referred to the place as Cafe Dead. Somewhere along the line it was noticed that this was a HEX number. I was re-vamping some file format code and needed a couple of magic numbers: one for the persistent object file, and one for classes. I used CAFEDEAD for the object file format, and in grepping for 4 character hex words that fit after "CAFE" (it seemed to be a good theme) I hit on BABE and decided to use it. At that time, it didn't seem terribly important or destined to go anywhere but the trash-can of history. So CAFEBABE became the class file format, and CAFEDEAD was the persistent object format. But the persistent object facility went away, and along with it went the use of CAFEDEAD - it was eventually replaced by RMI."