URL structure within MMS specified in accordance with the design principal of exposing implementation detail. The URLs use natural keys for entities, and are structured such that they match the hierarchy of entities they relate to. Natural keys mean it is clear what the URLs correspond to, as well as improving discoverability of URLs. Users who see an address containing a module code, are likely to understand they can replace that module code with another and arrive at the referenced module. The more common case of using primary keys in URLs is often opaque as the keys have no meaning to the end user.
In having URLs model the hierarchical structure, the system enables the dispatchers to handle many security constraints, minimising code duplication and in doing so reducing risk of subtle errors in implementation. This ties in with the design principal of modelling
the institution. Security implications of URLs are discussed in depth in the authorisation section of this chapter, see 5.7.2.
For example a URL referring to the list of students taking the module CS1002 in semester one of the academic year 2012/3 might be represented as:
https://example.edu/mms/module/2012_3/S1/CS1002/Students
The path up to and including “/mms/module/” is consumed by the web server, which maps the path element to the module dispatcher, and passes control to it. The module dispatcher then consumes the elements “2012_3/S1/CS1002/”, which identifies the module being ac- cessed, and “Students” which identifies the controller to pass the request to.
This structure means that a user who knows a module’s code and when it was running would trivially guess where the module would be in MMS’ address space, as well as making it easy to determine where a URL referred to (such as when presented in printed material). For tools instances, addresses identify not only the tool, but also the module they belong to, for example:
/mms/module/2012_3/S1/CS1002/Coursework/Student
Figure 5.2 shows how a URL is broken down into different elements which are mapped to a dispatcher, module, tool and finally entities within that tool. Each coloured layer represents a different component of MMS, the solid arrows progressing from top-left to bottom-right represent the request from a user traversing those layers. Text in italics describe the condi- tion to be applied to the request before it can proceed to the next layer (dashed arrows are used to indicate where a request can be rejected).
Requests for tools pass through the same code-path as requests for modules, before the tool path component is parsed and the request passed to a controller within the tool. This is important to the authorisation model, and will be discussed further in section 5.7.
/mms /module /2012_3/S1/CS1002 /Content /Lectures /Monday.pptx Is the user logged in?
Has access to module CS1002?
Has access to content tool?
Has access to “Lectures” folder
MMS
Module Dispatcher
Resource Dispatcher
Content tool
Folder
Figure 5.2: Decomposition of URL
5.5.1
Natural Keys for Content
With extension of the content tool in preparation for migration of content from WebCT, there was a need to support relative addresses, so that HTML pages uploaded to the tool can access images, stylesheets and other content at meaningful addresses. The tool dispatcher was modified to pass any remaining URL elements to the tool to be resolved into entities. For example an address for a file, before and after rewriting to the new structure, might appear as follows:
/mms/module/2012_3/S1/CS1002/Content/File?serial=3 /mms/module/2012_3/S1/CS1002/Content/index.html
Where alternative views of a file are required (for example to edit settings on a file), these are specified through use of a query parameter, for example:
5.5.2
Natural Keys for Coursework, Exams, etc.
This model can be extended to cover many other types of data, improving both readability and discoverability. Coursework submissions can be modelled in terms of assignment and student, and revisions specified if needed. For example:
/mms/module/2012_3/S1/CS1002/Coursework/Week1/
/mms/module/2012_3/S1/CS1002/Coursework/Week1/970123456/ /mms/.../Coursework/Week1/970123456/?view=download&revision=1 /mms/module/2012_3/S1/CS1002/Coursework/Week1/?view=spreadsheet /mms/module/2012_3/S1/CS1002/Coursework/*/970123456/
These URLs would reflect, in order:
1. All coursework submitted for the assignment “Week1” of CS1002.
2. Coursework for student 970123456 to the assignment “Week1” of CS1002. This would generally be the view showing details such as mark, feedback, mark history, etc.
3. Download the first file submitted by student 970123456 to the assignment “Week1” of CS1002.
4. A spreadsheet of marks for coursework submitted for the assignment “Week1” of CS1002.
5. All assignments for the student 970123456.
Exam URLs could also be structured to end in entity references of the form “<student>[’/’ <section> [’/’ <question>]] to provide similar benefits. Constraints on development time and complexity of managing large scale changes to addressing schemes have meant these have not been adopted in actual code, however the theory should be clear from these exam- ples.