COWB60352
Distributed Web Applications
Assessment Element 2: RESTful API
Learning Outcomes
- Demonstrate a systematic understanding of the patterns and practices
that go into making a suitable layered architecture for a web application. - Design, implement, test and critically appraise a web application.
- Extensively develop and apply web application functionality through web
api (application program interfaces) usage. - Demonstrate a critical understanding of consuming web api services on
different devices.
Important
All assignment work is to be completed individually.
University regulations on academic conduct1
and exceptional circumstances2 apply. Please
ensure that you are familiar with these regulations.
Schedule
Element Out In Method %
2
18/01/2021
0.00
Demonstration w/b
10/05/2021
Zipped copy submitted to
Blackboard (immediately following
the demonstration of your code)
40% - https://www.staffs.ac.uk/stud…
- https://www.staffs.ac.uk/stud…
School of Computing and Digital Technologies
2
Submission and Assessment
Submission is to Blackboard. A zipped copy of your code (not a rar file) should be
submitted immediately following your demonstration.
Submission will not be accepted by alternative means (such as email) so you should ensure
that your submission is made well before the deadline to avoid last minute problems.
There will be a scheduled demonstration slot for you to show your work. Failure to
demonstrate at the allocated time of your demonstration will result in zero marks for
this element of the assessment regardless of whether work has been submitted by the
deadline.
The marking criteria is provided at the end of this document. You should ensure that you
are fully aware of these criteria.
Scenario
You have been approached once more by College Road Swimming Club to create an API for
their new records management application so that it can be integrated with 3rd party
systems (other swimming clubs and the Amateur Swimming Association (ASA)).
The following is a reminder of their requirements for the records management application.
Outline
The new system needs to have the following core functionality:
• Authentication / authorisation of 4 different categories of user roles (guests,
swimmers, parents and club officials)
• The registration, storage and management of members details
• Entry of swimming event results
• Access to swimming event results
Swimmers
Swimmers are identified as children who swim for the club. A child can only swim for the
club with the permission of their parent.
Parents
Parents, including guardians, are an important part of the club and they are encouraged to
be as active as possible in supporting their children.
A parent can manage their children’s profiles.
Club Officials
Club officials work for College Road Swimming Club.‘Club official’is a general term for a
number of different roles.
For the purposes of the web application, the club official should be able to create a Meet
on the system, create an Event on the system, create and edit Parents and Swimmers on
School of Computing and Digital Technologies
3
the system, add registered Swimmers to an Event, and add Event results when the Event
has completed.
Meets
Swimming meets take place regularly. They have a Venue where they take place, and a
date upon which they take place.
A swimming Meet will include a number of Events.
Events
An event is a race.
Each event has an age range (Under 14 (junior), and Under 16 (senior)), a gender, a
distance, and a swimming stroke.
Authorisation levels
Guests
This is the base level of access available to all user roles whether or not they are logged in.
It is expected that the web application will be of general interest to the public. Access
should be available to:
• search swimming event results based on an age group, swimming stroke and / or a
particular swimmer’s name
• filter swimming meets by venue, or date range
Swimmers
When a swimmer has logged in they will be able to see everything that a Guest can see but
their experience will be personalised. This means that they should find it:
• easy to view their own performance
• easy to view the meets and the events that they are registered on
Parents
When a parent has logged in they will be able to:
• view and edit‘family’group profile data (address, contact phone number, and
email)
Club Officials
When a club official has logged in they will be able to:
• view, edit and archive the personal details of any member – if archived, the
member’s data should be retained but they will not have a login and should be
noted as no longer active
• create and edit family groupings – one parent with one or more dependants
• create and edit parents and swimmers
• create and edit a swimming meet and the events that take place during the meet
(this includes adding swimmers to the event)
School of Computing and Digital Technologies
4
Data
The College Road Swimming Club has made example data available (see the“Example Data
Set (Excel Spreadsheet)”on the Assessment tab on Blackboard). You can use this as a
starting point.
You should be aware of the following information which is going to be required:
• Member – Name, Gender, Address, Contact Telephone Number, Email, Date of
Birth
• Event –Age Range, Gender, Distance, Stroke, Round, Lanes (with swimmers name),
Times (or reason for not finishing)
• Meet – Name, Venue, Date, Pool Length
Assessment
Requirements
It may be necessary for you to make assumptions during your design or implementation.
Please make sure that you check with your tutor first if you do so.
Extra Credit
Extra credit will be given if you are able to show:
• knowledge and understanding in your use of your chosen development
framework
• examples of good practice in software development, including a clear separation
of concerns using a layered approach
• a clear understanding of how you are using HTTP to deliver your service
• how your API design is fit for the purpose required of it
• an understanding of how secure your API is.
The Demonstration
You are required to demonstrate your implemented application over the course of 20
minutes. You will be asked to show:
• testing of your API using Postman to demonstrate its functionality.
and any or all of the following:
• your implemented application showing how you have addressed the criteria given
above (specified in the section“Marking Criteria”below)
• an explanation of any code that you produce
• unit testing for your application.
School of Computing and Digital Technologies
5
Marking Criteria
Base Mark (30% of the mark for Task 2)
Criteria Mark
Club official creates a parent 2
Club official creates a swimmer 2
Club official creates a family group 3
Club official edits a members name 2
Club official archives a member 3
Create meet 2
Create event 2
Add swimmers to event 2
Input race time data to event 2
Parent can view family profile 1
Parent can edit contact number 2
Personalised view for swimmers (name and races involved in) 2
Swimming meet’s listed (all swimming meets) 1
Search swimmers by age (list of eligible swimmers) 1
Search swimmers by swim stroke 1
Search swimmers by name 1
List events for a swimming meet 1
Total 30
Unit Testing (5% of the mark for Task 1)
The unit testing mark is reliant on the attempt that you’ve made on the base mark criteria
above.
Criteria Assessor Guidance
Mark %
(fixed) Total
Unit testing No Base Mark criteria met. 0
5
Less than 16 in Base Mark criteria
OR
Testing is limited showing little evidence of progression beyond the
example tests provided by the framework. 20
Mark of 16-24 in Base Mark
OR
Testing is evident but is limited to the normal value test cases with little
evidence of testing beyond that. 40
Above 24 in Base Mark
AND
Testing shows a systematic approach with a good attempt to isolate unit
tests and testing was not limited to normal value test cases. 60
Base Mark criteria fully met
AND
Testing shows a systematic approach, tests work in isolation, and, while
some functionality might not be fully tested, the process of unit testing
was fully understood. 80
Base Mark criteria fully met
AND
Testing shows a systematic approach, tests work in isolation, and no
further tests suggested. 100
Total 5
School of Computing and Digital Technologies
6
Extra Credit (65% of the mark for Task 2)
The extra credit mark is reliant on the attempt that you’ve made on the base mark criteria
above.
Criteria Assessor Guidance
Mark %
(fixed) Total
Use of the
framework
No Base Mark criteria met. 0
10
Less than 12 in Base Mark criteria
OR
Limited use of the framework with little understanding evident. 20
Mark of 12-18 in Base Mark
OR
Framework utilised to create working application but leaving a lot of
scope for improvements to be made. 40
Above 18 in Base Mark
AND
Good understanding of the framework shown with good use made of
the functionality available but leaving some room for improvement. 60
Base Mark criteria fully met
AND
Very good understanding of the framework shown, making great use of
its functionality with limited scope for improvement and little need for
prompting or clarification of the explanation given. 80
Base Mark criteria fully met
AND
Excellent understanding and familiarity with the framework and making
full use of its functionality for the task in hand, with clear explanation
given. 100
Separation of
concerns
No Base Mark criteria met. 0
10
Less than 12 in Base Mark criteria
OR
Only evidence of a limited understanding of separation of concerns as a
concept. 20
Mark of 12-18 in Base Mark
OR
Evidence of a conceptual understanding of separation of concerns,
But limited practical evidence in the code produced with much room for
improvement. 40
Above 18 in Base Mark
AND
Good understanding of separation of concerns demonstrated although
prompting was required, and
Separation of concerns evident in the code but some suggestions were
made for improvement. 60
Base Mark criteria fully met
AND
Excellent understanding shown of separation of concerns with little
prompting required, and
Clear evidence of layers in the code and good separation with only
limited scope for improvement. 80
Base Mark criteria fully met
AND
Excellent understanding shown of separation of concerns, and
Clear evidence of layers in the code with evidence of separation and no
suggestions for improvement. 100
Use of HTTP No Base Mark criteria met. 0
15
Less than 12 in Base Mark criteria
OR
Limited use of HTTP Verbs and Headers and/or misunderstanding of
their purpose. 20
Mark of 12-18 in Base Mark 40
School of Computing and Digital Technologies
7
OR
Good use of HTTP Verbs and Headers showing an understanding of their
use.
Above 18 in Base Mark
AND
Good use of HTTP Verbs and Headers with a good understanding
demonstrated of their purpose in the wider context of web
development. 60
Base Mark criteria fully met
AND
Great use of HTTP Verbs and Headers with limited room for
improvement and based on a good understanding of the RESTful
architectural style. 80
Base Mark criteria fully met
AND
Excellent use of HTTP Verbs and Headers that adheres to the principles
of the RESTful architectural style and shows a clear understanding of
them. 100
Design of the API No Base Mark criteria met. 0
15
Less than 12 in Base Mark criteria
OR
Limited evidence of understanding of API design shown. 20
Mark of 12-18 in Base Mark
OR
API worked well with some consideration of the design evident but with
much scope for improvement. 40
Above 18 in Base Mark
AND
API resources are well-named and the data exchange works effectively,
A good understanding of API design is demonstrated but required some
prompting. 60
Base Mark criteria fully met
AND
API resources are well-named and the data exchange shows a good
understanding of API design with limited scope for improvement. 80
Base Mark criteria fully met
AND
API resources are well-named and the well-planned data exchange
shows an excellent understanding of API design with no suggestions for
further improvement. 100
Security of the
API
No Base Mark criteria met. 0
15
Less than 12 in Base Mark criteria
OR
The API security measures implement were limited with limited
understanding shown of security threats and their countermeasures. 20
Mark of 12-18 in Base Mark
OR
API security measures are evident but the explanation of security
threats and countermeasures was halting and required prompting. 40
Above 18 in Base Mark
AND
API security measures are evident with a good explanation of the
threats and countermeasures but with some prompting. 60
Base Mark criteria fully met
AND
API security measures applied with a good understanding shown of the
security threats and their countermeasures, little or no prompting
required and limited scope for improvement. 80
Base Mark criteria fully met
AND 100
School of Computing and Digital Technologies
8
API is secured showing an excellent understanding demonstrated of the
security threats and their countermeasures, clearly explained with no
prompting required.
Total 6