Hosting a website on AWS

Did you know that you can use CloudFormation to create and host a website on AWS?

I've been playing with EC2 to get the feel for AWS and in the process stumbled on a fun demo you can try--plus a few gotchas you might want to know before you try it.

I found a cool video, How to Launch a Website in 10 Minutes, on the AWS channel on YouTube. Basically, you create an S3 bucket to hold the website's resources, then you use CloudFormation to create an EC2 and an RDS instance, and install WordPress (and content) in the bucket. Very slick. It was a nicely done quick intro; however, I ran into a few issues:

• It's not under the free usage tier. The online docs (but not the video) warn you: this does cost money. The app also warns you when you create the EC2 and RDS instances. You're supposed to delete the instances as soon as you're done with the tutorial.
• The video tells you to select Upload a Template File (for the WordPress installation), but didn't say where to get the file. Apparently there are 2 or 3 different ways to specify a template. This can be confusing for a newbie. The online AWS tutorial is clear on this point, though.

It was a simple procedure--here are the basic steps:

• In the S3 tab, create a bucket and name it appropriately for your blog, e.g. amazing-blog.
• In the EC2 tab, if you do not already have an available Linux instance, create one.
• Upload all image files or other resources your blog will need to the bucket you just created.
• In the CloudFormation tab, click Create new stack. In the Create Stack dialog, provide the name of the bucket you created for the blog as the stack name.
• In Template, select Provide a Template URL, then type or paste the URL for the sample WordPress template, then click Continue. (This procedure is from the AWS docs; it's not noted in the video.)

https://s3.amazonaws.com/cloudformation-templates-us-east-1/WordPress_Single_Instance_With_RDS.template

The template contains several AWS resources including a LoadBalancer, an Amazon Relational Database Service DB Instance, and an Auto Scaling group.

• In the Parameters section of the dialog, provide the key name of an existing EC2 instance.

Cool idea, but is it worth it?

I left the WordPress website up for a few days to create fake content and mess with formatting. Then I noticed the meter was ticking on the EC2 and RDS instances. I did get charged a bit. To be fair, I was warned. The docs warn you about this, and instruct you to delete the resources as soon as you're done. The management console indicated an estimated monthly cost of $110. I'm not certain that the service comes to that much in real life usage, but it could be a very expensive blog!

IMO this demo was done more of a proof of concept--and a worthy idea. It could be worthwhile if your website required considerable web resources--for example, you had a large database of streaming audio files, or a catalog that would require a sizable relational database. But for your own personal blog, or even a small business website as demonstrated in the YouTube video, it's probably not a cost-effective option.

I admit I was taken with the idea of spinning up your own virtual hosting site, and I wish that AWS would offer a scaled down economy plan (not free but cheap...) for those who just want to spin up and discard experimental websites easily.

XMLHttpRequest2 in HTML5

I'm just now learning about HTML5; at first I shrugged it off as an inevitable evolutionary fusion of HTML 4 and XHTML 1.1. Yet it's not just a markup language; it's more an extended hybrid language that embraces and supports several application programming interfaces (APIs) for web applications. It's an open format that would allow development of cross-platform web or mobile applications.

For me personally, the most interesting inclusion is XMLHttpRequest support. Specifically, XMLHttpRequest Level 2.

As the HTML5 Rocks blog points out, it's being included to allow AJAX to work with HTML5 APIs such as File System API, Web Audio API, and these would support binary file transfer and streaming media. It's all spelled out in this excellent post: New Tricks in XMLHttpRequest2.

What's surprising to me is the lack of mention of the implication for RESTful web services. It seems that XMLHttpRequest support would be a major step forward in streamlining interoperability with web services, because--in theory--you'd be able to make RESTful requests directly from a web page. How would this implementation look in actual use? I'm thinking AJAX-like web page elements that can be updated by web services in real time.

Last.fm web services

This article is intended for readers with a programming background who are interested in REST web services. This text assumes the audience is familiar with the basics of REST web services programming.

Many web developers add streaming audio to websites using web services from one of the well-known streaming web players (AKA Internet radio), such as Spotify, Pandora, or Last.fm. Those who want to access the famous Pandora app will be disappointed, however. A bit of searching the web showed that Pandora once offered an open source API, but for whatever reason, deprecated it in 2012.

However, Last.fm offers a REST API that lets web developers access the functionality of its Scrobbler application. What's Scrobbler?

Scrobbler is the Last.fm client application, with which users can play Last.fm radio stations. It automatically fills users' libraries and updates them with what they've been listening to on their computers. Users can also rate music by "loving" and "banning" tracks, assemble playlists, and apply tags to tracks and albums.

What it does

The Last.fm REST API lets web developers use the same functionality in their own web or mobile applications, streaming music from Last.fm and using Last.fm data. The API goes a few steps further, offering tools for gathering statistics and accessing data by various collections (by group, by genre, by artist, etc).

It provides methods that let you operate on the following objects (which Last.fm calls "packages"):

• Album - Access data for an album
• Artist - Access data for an artist
• Auth - Fetch a session key or request token
• Chart - Access chart info for artists or tracks
• Event - Attend or share a live audio event
• Geo - ISO 3166-1 country and metro data for use in the other web services
• Group - Access data for a group
• Library - Maintains tracks/albums in a user's library
• Playlist - Access a user's playlist data
• Radio - Access metadata or streaming audio from a Last.fm radio station
• Tag - Access search tags
• Tasteometer - Access Tasteometer data (a rating score used on Last.fm)
• Track - Access data for a track
• User - Access user data Venue - Access data for a venue for events

How it works

In the Last.fm API, there are two ways to make requests: write operations (using POST) and read operations (using GET).

Write operations

To access a write service, you submit a request as an HTTP POST request to the service endpoint. You send all parameters in the request body. In order to perform write requests, you first have to authenticate a user with the API (not discussed here).

Example: How to "love" a track

(This service is described in the Last.fm REST API documentation at http://www.last.fm/api/show/track.love.)

The track.love method is a write operation and uses HTTP POST. You should send parameters (including the method parameter) in the POST request body to the service endpoint at http://ws.audioscrobbler.com/2.0/.

Parameters

track (Required) : A track name (utf8 encoded)
artist (Required) : An artist name (utf8 encoded)
api_key (Required) : A Last.fm API key.
api_sig (Required) : A Last.fm method signature. See authentication for more information.
sk (Required) : A session key generated by authenticating a user via the authentication protocol.

Request Body
In a write operation, params are sent in the request body of HTTP POST requests as named arguments using a structure as follows:

<methodCall>
 <methodName>track.love</methodName>
 <params>
  <param>
   <value>
    <struct>

     <member>
      <name>track</name>
      <value>
       <string>Ring of Fire</string>
      </value>
     </member>

     <member>
      <name>artist</name>
      <value>
       <string>Johnny Cash</string>
      </value>
     </member>

     <member>
      <name>api_key</name>
      <value>
       <string>AA25BB53CC45DD85EE22FF30GG67HH64</string>
      </value>
     </member>

     <member>
      <name>api_sig</name>
      <value>
       <string>BB89CC55DD80EE11FF41GG07HH18II99</string>
      </value>
     </member>

     <member>
      <name>sk</name>
      <value>
       <string>CC12DD45EE67FF24GG56HH88II36ZZ00</string>
      </value>
     </member>

    </struct>
   </value>
  </param>
 </params>
</methodCall>
Read operations

To access a read service, submit a request as an HTTP GET request to the service endpoint. You send all parameters in the request URI. You don't have to authenticate a user with the API to perform read operations.

Example: How to get metadata info on a track

The track.getInfo method is a read operation that uses HTTP GET.

http://ws.audioscrobbler.com/2.0/method=track.getInfo
&track="Ring of Fire"
&artist="Johnny Cash"
&username="MrHat"
&api_key=AA25BB53CC45DD85EE22FF30GG67HH64

Parameters

mbid (Optional) : The musicbrainz id for the track
track (Required (unless mbid)] : The track name
artist (Required (unless mbid)] : The artist name
username (Optional) : The username for the context of the request. If supplied, the user's playcount for this track and whether they have loved the track is included in the response.
autocorrect[0|1] (Optional) : Transform misspelled artist and track names into correct artist and track names, returning the correct version instead. The corrected artist and track name will be returned in the response.
api_key (Required) : A Last.fm API key.

Sample Response

<track>
  <id>1019999</id>
  <name>Ring of Fire</name>
  <mbid/>
  <url>http://www.last.fm/music/JohnnyCash/_/RingOfFire</url>
  <duration>240000</duration>
  <streamable fulltrack="1">1</streamable>
  <listeners>69572</listeners>
  <playcount>281445</playcount>
  <artist>
    <name>Johnny Cash</name>
    <mbid>bfcc6d75-a6a5-4bc6-8282-47aec8531818</mbid>
    <url>http://www.last.fm/music/JohnnyCash</url>
  </artist>
  <album position="1">
    <artist>Johnny Cash</artist>
    <title>Ring of Fire</title>
    <mbid>61bf0388-b8a9-48f4-81d1-7eb02706dfb0</mbid>
    <url>http://www.last.fm/music/JohnnyCash/RingOfFire</url>
    <image size="small">http://userserveak.last.fm/serve/34/8674593.jpg</image>
    <image size="medium">http://userserveak.last.fm/serve/64/8674593.jpg</image>
    <image size="large">http://userserveak.last.fm/serve/126/8674593.jpg</image>
  </album>
  <toptags>
    <tag>
      <name>Country</name>
      <url>http://www.last.fm/tag/country</url>
    </tag>
    ...
  </toptags>
  <wiki>
    <published>Sun, 27 Jul 2008 15:44:58 +0000</published>
    <summary>...</summary>
    <content>...</content>
  </wiki>
</track>

Summary

Website:  Last.fm Web Services - http://www.last.fm/api

Documentation:  http://www.last.fm/api/intro

Service endpoint:  http://ws.audioscrobbler.com/2.0/

Supported HTTP operations:  GET, POST

Usage fees:  Free; must register for an API account

Comments:
The API is well-conceived and full-featured. Perhaps the most appealing aspect is the simplicity of method calls. The difference in how parameters are transmitted in GET requests (in the URI) versus POST requests (in the request body) is a distinctive feature that developers need to understand for this particular API. The only criticism I have for the documentation is that it should explain exactly how parameters are transmitted in the request body. In particular, the documentation should provide explicit code examples of how parameters are specified in GET and POST requests.

REST for the Rest of Us

This article is intended to be an explanation of REST for a non-technical audience. In particular, it's meant for people who perhaps have heard the ubiquitous phrase "software as a service" but who are otherwise not familiar with the working of the Internet.

I'd like to give credit for helping me sort out my thoughts on this article to a semi-famous essay How I Explained REST to My Wife. It takes a more roundabout conversational approach, but covers quite a few deep insights into REST.

The first thing you should know about the web is that there's no web. In reality there are millions of computers around the world connected by a sophisticated addressing system. All the content on these computers--web pages, images, digital video, streaming audio--as well as certain processing tasks, are resources.

The term "web" is simply a metaphor to emphasize that all these computers are connected and discoverable. The architecture of this "web" is based on REST, which stands for REpresentational State Transfer. It's a somewhat obscure way of saying that the state (like a snapshot) of the data that describes a resource can be represented and transferred in standard formats. It sounds obvious, but the web needs basic rules.

REST is simple, because it's not a programming language, library, or platform, but a design, an architecture. All it means is that you can access a resource on the web with a request, it's RESTful. So the term RESTful can cover a large swath of exceedingly different web services. It's often hard to say exactly what makes an application RESTful web service. This is how I'd explain it to a lay person.

Until fairly recently, the resources people wanted were typically files: web pages (HTML files), images (JPG and GIF files), audio (MP3 and WAV files). However, more recently, resources have been tasks such as reading activity feeds (e.g. Facebook posts), or database searches (finding products in online catalogs), or accessing local weather data. Resources can also be computing services, like file storage and backup, or performing large computations in the cloud. These latter services are what is commonly referred to as "software as a service."

However, thinking in terms of data or processing tasks can be a little abstract, so for the purpose of explanation, I like to think of resources as pizza. After all, if you can order a pizza on the web, it must be a resource.

Every resource on the web has an address called a URL. You can think of it as the street address or phone number of the pizzeria. It starts out specifying a more general area, then becomes more specific--just like a phone number: area code, local exchange code, and last four digits of the specific phone.

Here are the operations you can perform on resources on the web:

• You can POST a pizza by ordering it--thus creating one. The purpose of POST is to create a new resource.
• You can PUT pepperoni, or other toppings on the pizza, by changing an existing order. The purpose of PUT is to change or update data in an existing resource.
• You can GET a pizza when your order is ready. The purpose of GET is to retrieve a resource.
• You can DELETE a pizza by canceling the order. The purpose of DELETE is to remove a resource.

These four verbs are the only operations used in RESTful web services. REST services use one of these verbs plus the URL to access data or a processing service.

Whenever you click a link on a webpage, the web browser makes a GET request on the address contained in that link. The address is also called a URL or Uniform Resource Locator--because its purpose it to locate resources.

Here's a very simple example. Suppose a friend sends you an email with a link to a YouTube video. If your friend clicked "share," YouTube provides a short version of the URL:

http://youtu.be/o0MIFHLIzZY

Let's break this down: The first part of the URL (youtu.be) is a shorthand address that redirects the browser to the YouTube home. Then there is a slash, followed by a cryptic code (o0MIFHLIzZY). This is the unique resource ID of the video. (That is, the video is a resource, and every resource needs a unique ID.)

By clicking this link, you're directly accessing (that is, GETting) the resource by its direct address.

But there are many ways to access data on the web. YouTube also allows you to access the same video this way:

http://www.youtube.com/watch?v=o0MIFHLIzZY

Using this form, you provide the regular URL for YouTube (www.youtube.com), then a slash followed by 'watch'. This accesses the watch service, an application that plays a video if you provide an ID.

The way you provide parameters in a URL is to add a '?' followed by parameter_name=parameter_value. In this case it's 'v= o0MIFHLIzZY'; the parameter name is 'v' and the value is the resource ID.

Specifying parameters is one way to provide information to web services. It's the typical way to provide information to web search applications such as Google search.

SOAP vs REST web services

This article is intended for readers familiar with web programming, but who are not yet acquainted with SOAP and REST technologies.

Many web service providers offer both a SOAP API and a REST API, so the consideration of which to use comes up moreoften than you'd think. Each technology has attributes that make it more or less suitable for various purposes. The typical scenario is that companies first write SOAP methods, then port their SOAP API to a REST API. In such cases, where customers are presented with both APIs, this article might be helpful in deciding which way to go.
 
What's the difference?

If you were to ask me what's the difference between SOAP and REST in an elevator, and I only had 15 seconds to explain, I might offer this very basic, brief statement:

• With SOAP, you make method calls to invoke application operations remotely.
• With REST, you make HTTP requests to create, delete, update, and retrieve remote data.

Obviously there's a lot more to their implementation and architecture than that. But with regard to function, that's essentially it.

However, if the elevator were then stuck between floors, after relating all my aches and woes, I'd finish my explanation as follows.

Let's look at commonalities and differences.

What do they have in common?

Both SOAP and REST are service oriented architectures (SOAs). SOA is a generic term for architectures that allow applications to interact remotely through mutually understood standard interfaces. There are other SOA protocols such as RPC, CORBA, DCOM, and WCF, but we're only considering SOAP and REST here.

For an end user, there's no discernible difference in the operation of REST and SOAP web services. Their purpose appears to be the same--to access information in a language- and browser-agnostic manner, using a disconnected, stateless transfer model. If implemented properly, each is reliable, secure, and reasonably efficient for its intended application.
For a developer implementing a web service application, however, there are many differences to consider.

SOAP: Simple method calls over a wire

Simple Object Access Protocol (SOAP) is a software architecture that allows applications to consume web services by means of method calls. Your application calls methods that execute on a remote server. The data can be transported via various transport protocols such as HTTP/S, DCOM, or SMTP (HTTP is most commonly used).

You call SOAP methods as you would any method call, except that with SOAP, method execution is performed remotely. This makes SOAP language agnostic. You can call a SOAP method from an application written in any language, and execution occurs on a remote server. The method call only needs to know the signature of the web service interface (the parameters and return type) and the service endpoint (the address of the web service on the server).

A SOAP application uses Web Services Description Language (WSDL) to define how the service is called. This info is contained in a .wsdl file in the project. The WSDL defines what operations are available on the server, the method signatures of these operations (parameter and return types), and the address of the service endpoint for the operations.
SOAP transfers request and response data as XML text in a structured message consisting of a SOAP envelope containing a header and a body. The header contains application-specific metadata such as authentication and encoding. The body contains the actual SOAP data sent--either input data sent to the service endpoint for processing, or result data that the server returns to the client.

REST: All the web's an address

Representational State Transfer (REST) is a software architecture based on client-server interaction. A client application sends standard HTTP method requests to a remote server, which processes the request and returns a response. Applications often use HTTPS for secure data transfer. REST is a disconnected, stateless transaction model. A client request contains all the information necessary to service that request; session state is stored on the client.

The standard HTTP calls correspond to operations on resource data, similar to CRUD (create, read, update, delete) operations, as follows:

• GET corresponds to a read operation
• PUT corresponds to an update operation
• POST corresponds to a create operation
• DELETE corresponds to a delete operation

REST calls are simple; the critical part is understanding the underlying resource model that you are addressing. When you make a REST call, you execute a particular operation on a particular resource at a particular address. This operation has a context, much like a verb-object context.

In the REST model, everything on the web is considered a resource. All data, such as text, images, audio, etc., are resources, as are data processing and data access services. For example, a web service could look up an address for a specified contact, or edit that contact, or reformat the phone number that the user provides before writing it to the contact entry.

Each resource has an address represented by a Uniform Resource Identifier (URI), the address of the resource in the resource model. The exact structure of the URI depends on the web service's particular architecture. In general, it consists of a base URI, which defines the service endpoint address, followed by an extended address for resources and subresources. All REST APIs expose resources in a hierarchical structure called a resource model, in which each resource has a specific URI path.

A client application can send data either as parameter data in the URI, as header data, or in the request body. Response data is returned by way of the request body. Request and response data can be sent in a number of different formats such as ATOM, JavaScript Object Notation (JSON), RSS, POX (Plain Old XML).

How they stack up in comparison

Transfer protocols

• REST is limited to HTTP.
• SOAP is not limited to any one transfer protocol. SOAP can transfer data using other protocols such as SMTP, TCP/IP, named pipes, or message queues. Also, SOAP doesn't use standard HTTP requests but rather makes direct method calls over HTTP. Therefore the call doesn't have to originate from an application running in a web browser.

Service endpoint

• With REST, you must fully understand the resource model in order to use it. REST calls are simple, but the client needs to call the correct address with the correct HTTP verb. Resource models can be extensive and complex. This is not a disadvantage of the architecture, but it can be confusing if the resource model is not well understood. (Hence it's critical that the REST API documentation exposes the resource model.)
• In SOAP, calls from the client application must match the method signature of the SOAP interface being called.

Agnosticism

• REST is ideally suited for web applications; you can access web services from web applications in any browser. Because it only uses standard HTTP commands, REST functionality is browser agnostic. Operations are extremely simple, yet can access sophisticated functionality on the remote server (for example, identity verification and authentication). It is ideal for secure transactions such as online banking. Because it is disconnected, session state can be preserved.
• SOAP is language agnostic; you can make the call from an application written in any language, and execution occurs on a remote server. However, you must make sure that the type of data sent matches that required by the SOAP interface. Because the data is transported in a standardized structure, it makes a web service widely accessible.

Data format and transfer efficiency

• REST supports several data formats such as JSON, Atom, and POX (XML), and can transfer data as binary streams to increase throughput efficiency. Clients can cache responses, so you can reduce client-server interactions and improve performance.
• SOAP transfers data as verbose XML, so the messages are larger than binary data formats, and performance is slower than competing protocols. It might not be the best protocol for applications that compute or transfer large data sets.

Ease of use/implementation

• With REST, all you need to call the service is a browser. The API is super simple--only the four HTTP methods and the URI--but you need foreknowledge of the service endpoint and the address of each resource. Also, then your client app needs to parse and interpret the response from each call.
• With SOAP, you can discover the service with the WSDL service description, which can give you a usable client proxy. The XML returned by SOAP calls is easy to interpret.

 
The elevator starts moving, so in conclusion...

To conclude, there's no right answer. Both technologies are extensively used and well-proven. While you could argue that REST has been around since the beginning of Internet time (as long as there has been an HTTP request), it's considered the newer technology. SOAP has enjoyed a lot of corporate support, but never caught up with REST. SOAP started out strong in the early millennium, but it's distinctly falling from grace. As one example, Ruby on Rails dropped SOAP from its core framework in 2007.

This is not to say you shouldn't choose SOAP. It's simply that there are compelling reasons why REST is so much more appealing.

Make your postings highbrow with drop cap

Or, Drop Cap: another stupid JavaScript trick.

A "drop cap" is one of the more exotic pyrotechnics in the typesetter's aresenal. You often see it in highbrow magazines like the New Yorker where the first letter of an article is oversized, or boxed, or surrounded by a design. It's simply a way to start an article out with a flourish. In the old days, they simply put in a block for the big initial and arranged the other letters around it.

But working in HTML, I found it wasn't simple at all. If you just specify the font of the first letter as "font-size: x-large;", it will render larger, but it won't "drop down" into the lines of text as it's supposed to.

Lorem ipsum quia dolor sit amet

After some poking around on the Internets, I found a way to do it using JavaScript. At first I thought it was too much coding for what you got out of it--but then, so is pretty much any coding on a sophisticated web page. In the final analysis, yes, it's a stupid JavaScript trick to fancy up your blog postings, but it's also a fairly simple, elegant example of using a JavaScript class, which defines a CSS style, and is located in the head of the web page.

This is the JavaScript I'm currently using:


<style type="text/css">
.dropcap { font-family: "Book Antiqua", serif; font-size: 3em; float: left; border: 1px double #000000; padding: 10px; margin: 0 5 0 0; }
</style>

<span class="dropcap">L</span><span style="font-family: &quot;Trebuchet MS&quot;, sans-serif;">orem ipsum quia dolor sit amet<span>


It renders as follows:



Lorem ipsum quia dolor sit amet

Who's afraid of javascript:void()?

Very few people, apparently. It's used all over the place. In fact I had been using that old chestnut, javascript:void(0), for quite some time to implement popups on my blog. I'd read somewhere that this is considered bad coding practice, but I didn't know exactly why. So, kids, if you take away nothing else from this article--learn this worldly lesson: you can find the solution to just about any coding issue by searching on Google.

You can search, but the results usually answer your question obliquely. After reading a few blog posts, I finally found out why you should avoid void(). (In the interest of full disclosure, the clearest of these articles was Javascript href Voids and More.)

There are good parts and bad parts to JavaScript; it is in fact a full-fledged, object-oriented language, but it has features that allow you to write code sloppier than a 4-year-old plowing through a Big Mac. One of these pitfalls is using void() in a link, because it's an easy hack. The technical reason to avoid void(0) is that it can produce indeterminate results on some browsers, or when Javascript is disabled on the browser.

So let us say that we'd like to implement a popup that provides the English translation of a German word. The following script uses void(0) to generate a popup saying "German for 'so-called'" when you put the mouse over the word "sogenannte:"

<a href="javascript:void(0)" title="German for 'so-called'"><em>sogenannte</em></a>

Try it by positioning the mouse over the word below:

sogenannte

Here's the preferred method: Instead of using void(), set href to "#", which is a kind of shorthand meaning "this page." Handle the onmouseover event by returning false. Also disable clicking on the link by making the onclick event return false:

<a href="#" onclick="return false;" onmouseover="return false" title="German for 'so-called'"></em>sogenannte</em></a>

Now position the mouse over the following link:

sogenannte

Using '#' as a substitute for the void() function is supported by all major browsers and is considered to be the correct method. If you're concerned about how this would behave when Javascript is disabled in the browser, you can replace '#' with a valid URL; a good choice is to insert the URL of the same page on which the link resides. The user will see a refresh, but will stay on the same page.