kablooie

I was trying to explain Idempotency and Safety to my colleagues. Initially, they had a hard time grasping the difference between safety and idempotency. I then used a mathematical example to explain these terms and it seems to have gone well with them.

Here’s how I explained…

The HTTP’s uniform interface have two important properties; Idempotency and Safety. i.e some HTTP methods are safe (GET & HEAD) and some are idempotent (PUT & DELETE). Safe methods (GET,HEAD) are automatically Idempotent but the reverse is not true. i.e PUT and DELETE are idempotent and not safe.

Safety means that the method will not have any effect on the server state. A GET and HEAD are readonly request and it is expected not to cause any state changes on the server. Idempotentcy means that the method can be invoked any number of times and the result will be same. e.g. DELETEing a resource any number of times results in same state i.e resource deleted state.

The following example from mathematics will further explain safety and idempotency:

• 8 * 1 * 1  * ….. = 8 (This is a safe operation, the result (8) will not change regardless of how many times we multiply 8 by 1)
• 8 * 0 * 0 * ….. = 0 (This is not a safe operation but it is Idempotent, the result changes (becomes 0) and remains so regardless of the number of time we multiply 8 by 0). Note, this is not safe because the 8 * 0 changes the result the first time.

I had taken MIME for granted and not really bothered to understand how MIME did what it did until recently. As I have started to design a WOA for one of our systems, I am dragged into more and more such technologies.

A brief about MIME:

MIME stands for Multipurpose Internet Mail Extensions. It specifies a set of extension to the standard Internet mail system. However, its use on the web is not limited to Internet mail but is used extensively on the Internet in general.

The main features of MIME are:

• Support for Non-ASCII character sets
• Describing Content type
• Support non text content (read binary like images, video, audio etc..)
• Support for multipart messages.

The familiar Content-Type header in HTTP is used to indicate the media type used. For example, Content-Type : text/plain; charset=”ISO-8859-1″ indicates that the text used in the payload follows the ISO 8859-1 character set standard. This header (in HTTP) provides useful information about how to interpret the message to any program. Similarly, supporting non ASCII data like gif, jpeg or audio/video is also possible through the use of MIME type. Multipart messages (compound messages that contain text, images, and other binary format) is also possible through the use of MIME. Each part in a multipart document is separated by boundary lines and non ascii data such as images are encoded in base64. A MIME type consists of a primary type and a subtype (in text/plain, pirmary is ‘text’ and the subtype is ‘plain’). We can register our own MIME type at IANA to support any custom media types for our application however this is not mandatory if the application is not internet scale. In designing our applciation we plan to use/define our own media types first and then see if any standard types can be used for our requirement. We also plan to use the Content-Type HTTP header for versioning as described here.

Overall, I think MIME is a very powerful and convenient way for describing what your content is with regards to the format of the data or versioning of your HTTP or REST based application or to describe what constitues your message.