Danesh is currently testing the API but is a bit confused about the way that Severin tested some other API. He has been struggling with understanding shoulda functions. He also wrote a blog post containing information on the API for managing users. He would also get the information on his blog post up on the wiki.

Misa is currently waiting her review to pass.

Karen was wondering if the remark requests feature was ready to be demoed at Research In Action (RIA) showcase at the University of Toronto. However, the review request for the feature had not passed yet. Severin and Misa intend to coordinate to get the remark request feature up and running for the RIA demo.

Karel just finished classes and would be able to put in more time into Markus now. He is currently working on the functionality of deleting items and would get it done by the end of the week.

Bertan put up a review today and he is waiting for responses. Meanwhile he would be writing tests for the feature.

Tobi has been able to create a modal dialog for role switching. However, he has a problem with loading the index page of the user whom the admin is trying to assume the role of. The problem is with AJAX requests. He intends to fix the problem by tonight and would also finalize tests for the feature.

Ibrahim just finished fixing a bug in the annotation categories drag and drop. He would also be writing tests.

The UCOSP steering committee will be meeting next week to sort out most of the marks and other stuff, so Karen would like everyone to send her a note before the end of the week.

For those of you that need a little bit of background information on API, it’s what we use to send an HTTP request to the server to perform some standard HTTP tasks. The way you send an HTTP request to a MarkUs server is using the files located at

lib/tools/api_helper.{py,rb}

I prefer using the python script so here’s an example of a request using it. Here’s an example of using the script in general. If you want specific examples, try looking at the help option.

You need to have your API key stored somewhere in a text file. You can find it at the bottom of the index page once you’ve logged in (TAs and Admins only).
RoR recognizes 4 requests:

GET

POST

PUT

DELETE

The API that I implemented handles them with respect to the users in your current database.

GET – Show user
This displays a given user’s details using in-line text rendering. It takes in a key value of user_name=foo and will print out the user_name, first name, last name and the user’s type (admin/TA/student).

POST – Create user
This request creates a new user if it does not exist already. It checks this based solely on user_name You need to pass in the user_name, last_name, first_name and user_type. The options for user_type are “admin”, “ta” or “student”. Passing in an existing user or invalid user_type causes an error.

PUT – Update userSends the server a request to update an existing user. You choose the user you want to update through the user_name key and update the attributes through first_name and last_name. The request also takes an optional new_user_name key that you can use to change the user’s user_name. If you don’t pass this, it will simply not change. If the user does not exist or any of the parameters

DELETE – Delete userSeeing as you should never be deleting a user, the server just renders a 404.

Everything seems to be running smoothly but I’m going to add some functional tests to make sure authentication is actually working and that each of the functions are doing what they are supposed to be doing. The ideas I’ve got so far are as follows.

Give an incorrect authentication key and check that the correct error is rendered.

Create a user using the API and then manually check for it in the database. Also assert that the attributes are correct.

Send a GET request for a newly created user and check that the response against a preformated string. Note that this will have to change if respond_to is implemented (see below).

Update the first and last name of a new user that I temporarily create. Check the database to see if they attributes changed but the user_name remained the same.

Update the user again, this time also changing the user_name. Assert that the database contains a user with the new user_name and correct attributes and also assert the old one no longer exists.

Any other suggestions? I figured deleting doesn’t need an actual test because it renders the 404 when I try to send a DELETE request. I’d say that’s sufficient enough.

For a future project, I’m going to try to implement the rails respond_to function that renders a specific format for GET, depending on the user’s wishes. The hope is that you can simply enter

http://url.to.markus.com/api/controller/foo.json

and it would automatically render XML. There are two approaches to this implementation, both of which use the respond_to function. The easier way is hopefully that RoR recognizes the extension and the call to an API and does it for you. This way it would just be checking the requested format. The slightly more complicated approach is to modify the HTTP request by adding an additional key value pair for an Accept key. This key:value would have to be added to the request header’s list so the easiest way to do that is directly through the script. I am open to any other suggestions though I won’t start working on this until I’m done testing.

Here are examples for each of the requests, in case the general example wasn’t clear enough.

Before the end of the term, everyone should email Karen a little report consisting of what you accomplished this term, the current state of your work, what you plan to do to complete it, and a self-assessment. Remember to include links to any blog posts you wrote.

Misa will be writing a blog post about the userdocs as soon as she gets a ship it.

Karel is very busy with school, and won’t be able to work on MarkUs until after the 6th.

Yansong has stopped working on Markus for the time being. He will resume after his final exams.

Ibrahim has a bit more work to do for his drag and drop annotation categories before the end of the term.

Danesh has finished the marking state error bug and is implementing tests for the Users API.

Tobi is wrapping up the role switching item and is writing tests and implementing a modal dialog for it.

Bertan has been very busy and is working on converting ActiveRecords into YAML.

There will be two more meetings, a regular one next week and the postmortem.

There was a lot of talk about working on MarkUs after the term is over. I look forward to continuing to work with everyone staying on the project. 🙂