Skip to content
Pedro Felix edited this page Apr 3, 2017 · 1 revision

Introduction

This document describes the requirements for the second phase of the Software Laboratory project.

Requirements

Command request structure

On phase 1, the command request structure was composed by three components: method, path and parameters

{method} {path} {parameters}

For phase 2, this structure is added with a new optional component, called headers, placed after the path and before the parameters

{method} {path} {headers} {parameters}

The headers component is composed by a sequence of name-value pairs, where each pair is separated by the '|' character. The name is separated from the value by the ':' character. An example is

accept:text/plain|accept-language:en-gb

Multiple visualisation formats

All the GET method commands must support the accept header, defining the format for the outputted representation:

  • text/plain- plain text, similar to what was used in the first phase.
  • text/html - Hypertext Markup Language (HTML).
  • application/json - Javascript Object Notation (JSON).

An usage example is GET /courses accept:text/html

If the accept header is absent, then the text/html format should be used.

The GET methods must also support the file-name header, defining the file system location for the outputted representation. If this header is absent, then the representation is written into the standard output.

Paging

All the GET commands that return a sequence of items (e.g. GET /programmes and GET /courses) should support paging, i.e., the ability to return a subsequence of the original sequence. This paging is defined by two parameters (name-value pairs in the parameters set):

  • top - length of the subsequence to return.
  • skip - start position of the subsequence to return.

Both these parameters are optional. For instance the command GET /courses accept:text/html skip=6&top=3 returns the programmes subsequence starting at the seventh programme and ending on the ninth programme, using the HTML format,

Additional Commands

The developed application must support the following additional commands.

  • POST /courses/{acr}/classes/{sem}/{num}/students - adds a new student to a class, given the following parameter that can occur multiple times (e.g. numStu=12345&numStu=54321).

    • numStu - student number.
  • GET /courses/{acr}/classes/{sem}/{num}/students - shows all students of a class.

  • DELETE /courses/{acr}/classes/{sem}/{num}/students/{numStu} - removes a student from a class.

  • PUT /teachers/{num} - updates an existent teacher, given all required parameters.

  • PUT /students/{num} - updates an existent student, given all required parameters.

  • GET /courses/{acr}/classes/{sem}/{num}/students/sorted - returns a list with all students of the class, ordered by increasing student number.

  • OPTION / - presents a list of available commands and their characteristics.

  • EXIT / - ends the application.

Interactive operation

If the application is called with empty arguments, then it should enter into an interactive mode. In this mode, the application repeatedly reads a line from the standard input and executes the corresponding command. This repetition is stopped by the execution of a command with EXIT method.

Delivery date

The phase 2 must be delivered until 29 April (end of week 8), via the creation of a 0.2.0 tag on the GitHub repository.