A04. Reslet Code Katas

We (ICS414) have started to use Restlet, which is a java framework that will allow us to familiarize ourselves with the REST methodology.

What is REST?

I myself still am a little unclear on the uses and applications of REST, but I'm sure that as the semester progresses, it will become clearer. As I understand things, REST is a way for web servers to talk to one another and it facilitates more computer-to-computer interaction. One of the main pillars of REST that we've been examining in class is the use of representations of data. Rather than having static html code, a client can request a representation of some data. Perhaps that data will be displayed in text. Another client may request the data as a chart. Either way, the data is unaffected by these representation requests.

There are a few main components that comprise the REST architecture:

• Resources - these are 'things' like data or images
• Unique URIs (Uniform Resource Identifier) - this is the address or location of the resources
• Representations - this is how resources are displayed or presented to the user. External users may not manipulate or change resources, but they can alter the way these resources are represented.
• Verbs - actions one can perform on resources. E.g., GET (asks for a representation of a resource) and PUT (adds or updates a resource).

RESTLET

Our intro to Restlet included the following four code katas:

• Kata 1: Add three new resources called "hour", "minute", and "second" that return the current hour, minute and second (include unit tests).
  
  Experience: this was a very basic exercise that I was able to complete fairly quickly. It mostly involved copying packages and refactoring the names to match the new unit of time that needed to be displayed.
  
  Duration: 30 min

• Kata 2: By default, Restlet logs data about each request to the command line using the Java Logging API. Read a tutorial (and/or google) to get familiar with the API, then do the following: define a ~/.dateservice/logging.properties file that enables the user to specify (among other things) that the logging information should go to a file, not the command line tell the restlet-dateservice application to read and use the logging properties file in ~/.dateservice/logging.properties
  
  Experience: This was a little more challenging, since this is the first extensive use of logging that I've dealt with. After finding out how to use System.getProperty() to retrieve the home directory, however, the rest of the time was spent researching how to get the logging service to output to a file rather than the command line. I was able to read through a few logging configuration files and extract the necessary properties.
  
  Duration: 3 hours
  
  
• Kata 3: The current restlet-dateservice system performs no authentication. Check the user guide (and/or google) for guidance, then implement HTTP Basic authentication for all the resources in the restlet-dateservice system. To simplify things, all resources should be available as long as the requesting system uses HTTP Basic authentication and passes the username "guest" and password "pw". (You can hardcode that password into both the client and server sides of the system if you like.)
  
  Experience: I was able to find a fairly comprehensive tutorial for HTTP basic authentication with Restlet on StackOverflow: Click Here. This was pretty straightforward as far as adding authentication to each resource and then adding in the client-side hard-coded password/username combination to allow for the JUnit tests to pass. I initially tried to use the Restlet tutorial on access control, but due to lack of a comprehensive example, it wasn't very helpful.
  
  Duration: 2 hrs
  
  
• Kata 4: create a new client for the DateService server that is a web application using Wicket rather than a command line application. The web application should bring up a single page with a single form that requests what aspect of the date (year, month, day, hour, minute second) the user desires. When the user submits the form, the web application uses Restlet to obtain the appropriate information from the DateService server, then presents the results to the user in the page.
  
  
Experience: This was by far the most time-intensive of the katas. I first had to figure out that to get Wicket to interact with the Restlet server, I had to make an instance of a Jetty web server from last semester. Then, using the code from the Restlet client, this allowed my Wicket page to access and display the information as specified. I also need to brush up on my Wicket, and I wanted to better understand using form buttons to update a label, so I had to do some additional reading. In the end, I think I have a better grasp of how servers can talk to one another. Where one server can grab data from another server and display it using whatever framework is requested. For this particular exercise, we knew that Restlet was framework being run on the source server, so it made it easy to request data using Restlet type commands. It'll be interesting to see if the framework must be known or if there's some generic/standard interface that most servers use to communicate information between one another.

Duration: 5 hrs

TOTAL DURATION:

10.5 hrs

Distribution file (.zip): Click Here