REST

REST (REpresentational State Transfer) is an architectural style as defined by Roy T. Fielding in his Ph.D. thesis and according to an InfoQ article that I read, REST is a set of principles:

• Give every “thing” an ID
• Link things together
• Use standard methods
• Resources with multiple representations
• Communicate statelessly

By following REST principles, a system can transmit data to other applications without additional messaging layers like session cookies. I recommend reading the article if you're interested in learning more about REST. It'll explain REST way better than I can right now.

Special mention to the Beauty of REST article for using the word "grok" in the second to last paragraph. Stranger in a Strange Land reference anyone?

Anyway, I am working on a project called iHacky. It involves retrieving data from the Hackystat sensorbase, saving it to the iHacky database, then sending information based on that data to Facebook to be viewed.

The Hackystat sensorbase obeys REST principles. Looking at the Hackystat sensorbase REST api, it can be seen that there are resources that can be retrieved and links properties together as well as uses the GET, POST, PUT, DELETE, and HEAD methods. One part of Hackystat that I'm unsure of with regards to following REST principles is its project viewer. It has a URI, but I see nothing about it that leads to obeying REST principles.

The Facebook api on the other hand is only REST-like. Facebook provides a REST client library for its api written in PHP. The api can only make GET and POST requests so I suppose it's why Facebook considers their interface REST-like.

With regards to iHacky, I do not think a REST interface should be provided. I consider all the data that will be stored in the database to be confidential. The user must provide their Hackystat login and password in order for iHacky to retrieve their Hackystat data. If a user wants to retrieve their Hackystat data, they can go to Hackystat, if they want to retrieve our interpretation of their data, then all they need to do is look at it through Facebook. If a user wants to view another user's data, then they must go on Facebook and add iHacky to their list of applications and only view data that the other users' wish to provide. There are unforeseeable situations so I'm not closed to the idea of making a REST interface.

Introduction to Hackystat

Last night, I was introduced to Hackystat through the StackyHack tutorial. I was able to complete all parts of the tutorial successfuly. Each sensor (Ant, Junit, PMD, Checkstyle, and SVN) sent data to the Hackystat public sensor base.

I took approximately 6 hours to complete the tutorial because I was having some trouble setting up the environment. I'm not sure why, but in the past I was able to setup environtment variables on my Vista laptop and not have to restart afterwards. Now I have to. I didn't realize this after 2 hours of going over all possible mistakes I could have made. After I figured out that I had to restart, I spent another hour trying to figure out what mistakes I was making in the process of setting up the environment variables correctly for the ant sensor like putting in quotation marks for ANT_ARGS.

iHacky, the project that I am working on, will use either use Java or PHP, and mySQL. If my team decides on PHP the ant and svn sensors can at least be used. Doing brief research I found PHP equivalents for JUnit, Checkstyle, and Emma although I am not sure if these tools are mature enough to use for our project.

As for the three prime directives of Open Source Software Engineering, Hackystat fulfills at least the first two prime directives from my perspective. It accomplishes a useful task and it can be successfully installed by an outside user such as myself. As for the third prime directive, I understand the system, but I'm not sure about enhancing the system. That's what the project is for, in a way. Other developers have clearly enhanced Hackystat and understand it, so ultimately Hackystat fulfills the third prime directive.