辅导304CEM编程、讲解web/CSS编程语言、Java程序设计辅导 辅导留学生Prolog|讲解Python程序

日期：2020-11-21 09:38

This document is for Coventry University students for their own use in completing their
assessed work for this module and should not be passed to third parties or posted on any
website.
Faculty of Engineering, Environment and Computing
304CEM Web API Development
Assignment Brief
Module Title
Web API Development
Individual
Assignment
Cohort
Sept
Module Code
304CEM
Coursework Title (e.g. CWK1)
Coursework 1: RESTful API with client, video demo and short report
Hand out date:
29/09/20
Lecturer
Colin Stephen
Due date and time:
Date: 07/12/20
Online: 18:00:00
Estimated Time (hrs): 50-75
Word Limit for Report: 3000 / 8 pages
Length Limit for Video: 5 minutes
Coursework type:
Individual Practical plus Written
Report and Video
% of Module Mark
100%
Submission arrangement online via Aula: Upload through assignment link
File types and method of recording: 1x PDF document containing a written report and URL links (to two
git repositories and to your uploaded application demonstration video).
Mark and Feedback date (DD/MM/YY): 21/12/20
Mark and Feedback method: rubric marks and written comments
Module Learning Outcomes Assessed:
1. Develop a secure, open-standards-based API to support server-client communication.
2. Create modern web content involving asynchronous data retrieval, client-side DOM
manipulation, standards adherence and user-user interaction.
3. Manage data persistence cross both server and client web-based solutions.
4. Design and implement an API and client based on given, non-trivial requirements using a range
of appropriate developer tools.
Task and Mark distribution:
1. Back-end RESTful API: 40%
2. Front-end Single Page Application: 35%
3. Report on technology resources for full stack JS web development: 20%
4. Video demonstration of application functionality: 5%
Notes:
1. You are expected to use the Coventry University APA style for referencing. For support and
advice on this students can contact Centre for Academic Writing (CAW).
2. Please notify your registry course support team and module leader for disability support.
3. Any student requiring an extension or deferral should follow the university process as outlined
here.
This document is for Coventry University students for their own use in completing their
assessed work for this module and should not be passed to third parties or posted on any
website. Any infringements of this rule should be reported to
facultyregistry.eec@coventry.ac.uk.
4. The University cannot take responsibility for any coursework lost or corrupted on disks, laptops
or personal computer. Students should therefore regularly back-up any work and are advised to
save it on the University system.
5. If there are technical or performance issues that prevent students submitting coursework
through the online coursework submission system on the day of a coursework deadline, an
appropriate extension to the coursework submission deadline will be agreed. This extension will
normally be 24 hours or the next working day if the deadline falls on a Friday or over the
weekend period. This will be communicated via your Module Leader.
6. You are encouraged to check the originality of your work by using the draft Turnitin links on Aula.
7. Collusion between students (where sections of your work are similar to the work submitted by
other students in this or previous module cohorts) is taken extremely seriously and will be
reported to the academic conduct panel. This applies to both courseworks and exam answers.
8. A marked difference between your writing style, knowledge and skill level demonstrated in class
discussion, any test conditions and that demonstrated in a coursework assignment may result in
you having to undertake a Viva Voce in order to prove the coursework assignment is entirely your
own work.
9. If you make use of the services of a proof reader in your work, you must keep your original version
and make it available as a demonstration of your written efforts.
10. You must not submit work for assessment that you have already submitted (partially or in full),
either for your current course or for another qualification of this university, with the exception of
resits, where for the coursework, you may be asked to rework and improve a previous attempt.
This requirement will be specifically detailed in your assignment brief or specific course or module
information. Where earlier work by you is citable, i.e. it has already been published/submitted,
you must reference it clearly. Identical pieces of work submitted concurrently may also be
considered to be self-plagiarism.
Mark allocation guidelines to students – this applies to the code the report and the video. Please
see detailed rubrics at the end of the document.
0-39 40-49 50-59 60-69 70+ 80+
Work mainly
incomplete
and /or
weaknesses in
most areas
Most elements
completed;
weaknesses
outweigh
strengths
Most elements
are strong,
minor
weaknesses
Strengths in all
elements
Most work
exceeds the
standard
expected
All work
substantially
exceeds the
standard
expected
This document is for Coventry University students for their own use in completing their
assessed work for this module and should not be passed to third parties or posted on any
website. Any infringements of this rule should be reported to
facultyregistry.eec@coventry.ac.uk.
Assignment Brief
Scenario
As a full stack web developer, you have been asked to develop a Node based RESTful
API on the backend plus a React JS single page application (SPA) on the frontend to
replace a client’s existing unmaintained PHP-based website. In addition to the API
and SPA, the client requires a short report targeted at their internal development team,
exploring how the developed application fits in to the wider context of JavaScript full
stack technologies. Finally, the client has requested a short video demonstration of the
application, targeted at end-users.
Please choose ONE client from the list of two at the end of the brief for your
assignment.
The application specifications and requirements are set for you in the client’s project
brief. Please note that it is very important to follow the requirements and the design
considerations listed for each application. What follows next are instructions relevant
to all of the client projects.
Code – General Requirements
The application itself should be composed of reusable components rather than a single
stand-alone application. That means your code architecture should allow you to plug
in or extract any component easily from your application. For example, if you are
required to create a feature that allows users to comment on an item and reply to other
users’ comments, then you would develop a component to handle this commenting
functionality on its own, independent from and reusable in other full stack
applications when required.
Backend
All the backend services you develop should provide a Node JS based RESTful API.
This must communicate with your application using the JSON data format by default.
The Node frameworks and modules you choose to build the backend are up to you:
options include Koa, Express, Restify, and others.
Database
Similarly, the choice of database integration on the backend is up to you: options
include MySQL, SQLite, MongoDB, and others.
Frontend
All the frontend components you develop should be React JS components. In terms of
visual design the CSS framework you choose, if you decide to use one, is up to you:
options include React Bootstrap, Ant Design, Material UI, and others.
If in doubt as to the suitability of a particular framework, Node module, or DBMS
please ask the Module Leader first.
This document is for Coventry University students for their own use in completing their
assessed work for this module and should not be passed to third parties or posted on any
website. Any infringements of this rule should be reported to
facultyregistry.eec@coventry.ac.uk.
Code – Professional Practice
Your workflow, software architecture, coding style and conventions, and
documentation should follow general good practice as introduced in this module.
Above all:
? Your code should be consistent, readable and well documented. However,
your choice of specific code convention(s), such as using JavaScript Promise
chains versus async … await expressions, or what style you use to lint your
code, is up to you.
? Your API functionality should be clearly documented for other developers,
either in text-based documentation files (such as Markdown) in your
repository, or as HTML documentation created with a framework such as API
Blueprint or Swagger.
? Your SPA functionality should be clearly documented for end-users, either
in text-based documentation files (such as Markdown) with appropriate
screenshots, in your repository, or as HTML-based user documentation.
Code – Key Constraints
You should use only the programming languages and frameworks as advised in this
brief, no other alternatives are permitted:
? JavaScript with a preference for ES6 language constructs
? React JS on frontend
Written Report
Your client has asked for a background report to be compiled for their development
team, who are unfamiliar with the JavaScript full stack ecosystem.
The report should cover 6-8 one-page topics (see below for sources) chosen to
illustrate:
? the benefits of full stack for application development,
? how the JS full stack ecosystem is developing at its cutting edge,
? emerging commercial best practices the developers should be aware of.
To choose the topics and write the report:
? browse the archives of the following industry newsletters, or subscribe:
o JavaScript Weekly
o Node Weekly
o React Status
? choose 6-8 resources linked from them, keeping the report objectives in mind
? summarise each resource and explain its significance: why should the
development team be made aware of it (maximum 1 page per resource).
The final report should be clearly formatted for readability and include screenshots,
external references, and examples from your own application code when appropriate.
This document is for Coventry University students for their own use in completing their
assessed work for this module and should not be passed to third parties or posted on any
website. Any infringements of this rule should be reported to
facultyregistry.eec@coventry.ac.uk.
The maximum length of the report should be 8 A4 pages including references.
Video Demonstration
Your client wants to quickly introduce the new full stack application to its product
team and end users. For this purpose, they have requested that you provide a video
demonstration of the application functionality.
Produce a video walk-through of your application’s features and functionality using
screen recording software such as Microsoft Stream’s browser-based screen recording
or a one-person Zoom meeting recording with shared screen.
There should be no audio on the recording. Instead you must communicate using text
on the screen: e.g. prepare a slide deck with descriptions of the demonstration steps
being carried out.
The length of the video should be between 2-5 minutes and it must be uploaded to
Coventry University’s Microsoft Stream page (log in with your Coventry University
credentials).
The uploaded video can be private, but you must provide full access to Colin Stephen
(CU username ab5169) and be prepared to give access to other CU staff if requested.
A demonstration of how to do this will be given in class before the Coursework
deadline.
Task Summary
To prepare your final submission a rough breakdown of the key tasks is as follows.
First Steps
? Review the client projects at the end of this document and choose one.
? Decide on a database to use and a Node framework to build the API with.
? Sign up for the three industry newsletters linked above.
? Set up two repositories on https://github.coventry.ac.uk/304CEM-
2021SEPJAN, one for your frontend code and its documentation and one for
your backend code and its documentation.
? Prototype and plan your project based on the client requirements.
o Wireframe or sketch the UI, decide which UI components to develop
and decide how these will fit together in a React component hierarchy.
o Design a data schema for a database to store the API data you need to
manage. An Entity-Relationship diagram can be useful for this.
o Be clear on what the main resources provided by the API are.
o Design an appropriate JSON representation of these API resources.
Often this will parallel your DB schema, but it may differ if your
database contains additional information or relationships.
This document is for Coventry University students for their own use in completing their
assessed work for this module and should not be passed to third parties or posted on any
website. Any infringements of this rule should be reported to
facultyregistry.eec@coventry.ac.uk.
o Design the URI endpoints of your API and which HTTP methods can
be used to access them, corresponding to the resources you wish to
expose, using RESTful principles.
During Semester
? Develop your back- and front-end code with associated project and in-line
documentation using good version control practices and testing:
o Make regular small git commits with relevant messages.
o Develop features on new branches.
o Fix bugs on new branches.
o Merge branches with features and fixes to the master branch only once
complete.
o Write tests for key parts of your code using an appropriate test
framework such as Jest, Mocha, or Jasmine.
? Write your full stack development resource summaries in your report
o e.g. one page per week describing one relevant resource
? Extend your API documentation and end-user documentation as your code and
features develop.
Before Submission
? Commit your final code changes and merge all code to be assessed into your master
branch. Push all branches of your repositories to the remote origin branches in your
repositories on https://github.coventry.ac.uk/304CEM-2021SEPJAN before the
submission deadline. Code committed after the deadline will be ignored.
? Record a video demonstrating your final application, upload it to Microsoft
Stream and ensure the Module Leader (username:ab5169) has full access
before the submission deadline. Videos published after the deadline will be
ignored.
? Complete your report with an introduction and conclusion.
? Add a final blank page to your report and to it add three URL links to:
o your frontend repository on CU GitHub
o your backend repository on CU GitHub
o your uploaded video on CU MS Stream
? Export/Print your report-plus-URLs document to PDF format.
Submission
Upload a single PDF file, containing the following, to the assignment link on Aula:
? your report,
? the URLs for your repositories and video.
Files submitted after the deadline will not be marked unless you have been
awarded an extension or deferral from Registry.
This document is for Coventry University students for their own use in completing their
assessed work for this module and should not be passed to third parties or posted on any
website. Any infringements of this rule should be reported to
facultyregistry.eec@coventry.ac.uk.
Client Projects
Client 1 – We Sell Houses: A Real Estate Listings Web App
We Sell Houses would like a new web application that allows users (estate agents) to
list houses for sale to the general public.
Main features
? The general public can
o view a list of all items (properties)
o search/filter items based on their features and/or keywords
o view any item detail
o message item owners (estate agents) to express interest
? New users (estate agents) can register on the app if they have a sign-up code
o They need to supply a unique email and a password to sign up
o For this prototype the sign-up code is always “we_sell_houses_agent”
? Registered users can
o log in to the app
o see their current list of properties
o search/filter their current list of properties
o add a new item (property) for sale
o add or update the item category (commercial, terrace, apartment, …)
o add or update a description
o add or update a list of features
§ “has garden”,
§ “needs refurbishment”
§ etc.
o add or update an asking price,
o add or update the location
o attach or delete images
o mark as “under offer”
o archive/unpublish the item (property) from sale so it is no longer visible
to the public
o delete an item entirely
o mark an item as ‘high priority’
o view the current list of high priority items
o view all messages sent from the general public
o view, archive, or delete an individual message sent from the general
public
This document is for Coventry University students for their own use in completing their
assessed work for this module and should not be passed to third parties or posted on any
website. Any infringements of this rule should be reported to
facultyregistry.eec@coventry.ac.uk.
Challenge features – choose one or more:
? Agents can upload video walk-throughs for their listings
? Send in-browser notifications to the user when they receive a new message
? Use the Zoopla API, or similar, to provide agents with average historical
house sale prices in the location of their individual items, or other relevant
data. External data should be stored in your API database when retrieved, not
queried from the external API each time.
? Confirm the user’s email when they sign up by sending them an email
message containing a validation link that needs to be clicked to validate.
Client 2 – Public Library: A Book Lending Web App
Due to recent physical branch closures, a consortium of local libraries across the
country have teamed up. They wish to provide a platform for their members to lend
their books to one another online.
Main Features
? The general public can
o list all items (books) available on the site
o search/filter items based on their features and/or keywords (author, title,
ISBN, etc.)
o view any item detail
? New users can register on the app
o They need to supply a unique email and a password to sign up
o They must also provide a mailing address for book postage
? Registered users can
o log in to the app
o add new items (books) available for borrowing
o view individual book details
o update any fields describing their book
o delete a book they own
o attach or delete book images
o see a list of owned books
o search/filter owned books (author, title, ISBN, etc.)
o request or cancel a request to borrow another user’s item
§ only books not marked ‘on loan’ can be requested
§ only books not marked ‘requested’ can be requested
§ a short message to the lender can be added to the request
o view requests made and requests received
§ each request should also include any messages associated to it
o archive a request and its associated chat messages
o reply to messages in requests
This document is for Coventry University students for their own use in completing their
assessed work for this module and should not be passed to third parties or posted on any
website. Any infringements of this rule should be reported to
facultyregistry.eec@coventry.ac.uk.
o view user details of the user who is requesting a book
o mark any book as ‘on loan’
§ if the book had an open request then this request is removed
o mark any book as ‘available’ (meaning no longer ‘on loan’)
Challenge features – choose one or more:
? Send in-browser notifications to the user when they receive a new book
request
? Use the Goodreads API, or similar, to provide additional item information for
each book: reviews, author information, etc. External data should be stored in
your API database when retrieved, not queried from the external API each
time.
? Confirm the user’s email when they sign up by sending them a message
containing a validation link.
? Allow the user to download a CSV file of all currently available books in the
app.
This document is for Coventry University students for their own use in completing their assessed work for this module and should not be passed to third
parties or posted on any website. Any infringements of this rule should be reported to facultyregistry.eec@coventry.ac.uk.
304CEM Marks Breakdown and Rubric for Backend API (40%)
0 1 2 3 4 5
Version Control
5%
No access given
to the remote
repository.
Code does not match
the code demonstrated
or the project
requirements.
No evidence of regular
commits.
Evidence of regular commits. Evidence of regular
commits over an extended
period of time. Minor use of
branching.
Evidence of regular commits
over an extended period of time.
Effective use of branching and
merging.
API
Architecture
5%
No API code
supplied.
An attempt to write the
API however it fails to
work correctly.
All code for routing and
business logic
maintained in a small
number of files.
Code split into several smaller
files but shows overlap between
routing, business, and
persistence logic in places.
Clear separation between
core API routing, business,
and persistence logic.
Evidence of clear separation
plus encapsulation of
functionality into fully pluggable
and well documented modules.
API Design and
Testing
10%
No API code
supplied.
An attempt has been
made to implement a
basic API however this
does not work as
expected.
Simple functional API
demonstrating a basic
understanding of REST
principles (resources,
collections, methods and
headers).
The API is fully functional. The
API demonstrates a good
understanding of REST principles
with effective URI design and
JSON data representations.
Some attempt at testing
endpoints has been made but
this may be flawed or minimal.
The API provides feedback
for invalid requests through
appropriate response codes
and messages. Includes
filtering and sorting and
conditional GET requests.
Several API actions have
been tested.
Fully REST-compliant API
including implementation of
HATEOAS principles. Uses the
full range of request and
response headers and caching
where relevant. Many or most of
the API endpoints have been
tested with a standard test
framework.
Code Quality
and Unit Testing
10%
No API code
supplied. No test
code supplied.
An attempt has been
made to write code to
implement some of the
basic functionality
although this may not be
successful. No or limited
attempt at flawed tests.
Working code base
showing the application
of basic programming
principles. Code may
contain linting errors and
warnings. An attempt
has been made to write
some tests.
Well written code with
inconsistencies in some places.
Some code duplication. Would
benefit from mild refactoring.
Error handling is present but may
have holes. Validation is present
but may not cover all possible
issues. Evidence of a limited
number of tests written and run.
The code is modular,
follows a consistent style,
and includes full or close to
full exception-handling.
Data are thoroughly
validated before passing to
the persistence layer. Most
complex functions have
tests defined.
The API demonstrates a wide
range of appropriate language
constructs including clear
modular structure and use of
abstract design patterns or
paradigms such as functional
programming. Concise easily
maintainable code. Wide range
of relevant automated tests
defined.
User
Authentication
No user
authentication.
An attempt at user
authentication has been
Simple authentication
that allows users to login
An authentication system that
allows users to login using JSON
Fully working authentication
system using JWT or more
Fully working authentication
system that allows multiple
This document is for Coventry University students for their own use in completing their assessed work for this module and should not be passed to third
parties or posted on any website. Any infringements of this rule should be reported to facultyregistry.eec@coventry.ac.uk.
and
Authorization
5%
made but it is not
functional or is insecure.
using Basic Auth. There
is no difference in user
permissions or user
roles.
web tokens. Limited use of user
permissions or user roles.
advanced techniques.
Includes effective user
permissions and/or roles to
provide appropriate
protection to data.
different authentication
methods. Provides a flexible
roles and permissions structure
that allows an admin to manage
permissions without changing
code.
API and Code
Documentation
5%
No
documentation
provided.
Basic limited
documentation in code
and/or text documents
that does not add much
more understanding
than reading the code
itself.
Attempt at documenting
code or API but one or
the other is not fully
presented.
Both API and code are
documented well but could be
more detailed on key aspects
such as URIs or JSON data
structures. Code documentation
would benefit from a more
standardised approach such as
JSDoc or similar.
Clearly presented and
standardised
documentation on API URI
endpoints and JSON data
structures used by the API.
Code documentation uses
JSDoc or similar. Could be
easier to read or better
formatted
Extensive well formatted
interactive HTML-based API
documentation at a professional
level. Extensive relevant code
documentation adding clarity
and maintainability.
304CEM Grading Rubric for Front-end Application (35%)
0 1 2 3 4 5
Documentation
5%
No attempt Limited code
documentation and no
user documentation.
Or vice versa.
An attempt to comment
occasionally on the code, an
attempt to generate user
documentation but lacking
any detail.
Some of the code is
commented, an attempt to
generate user
documentation but still needs
more work to be complete.
Most of the code is commented
to a level that would help with
maintenance. A clear but short
user manual has been created.
Fully commented code using
JSDoc or similar, all user
functionality and every app
feature have been clearly
explained and professionally
presented.
Connecting to
APIs
5%
No code
supplied, or
no attempt to
connect to
the API.
An attempt for
connecting and
retrieving data from the
APIs was done but this
does not work or is
incomplete.
Some pages connect and
retrieve data from the API.
These may have minor or
major issues in connecting.
Some connections are not
attempted.
Most of the pages connect
and retrieve data from the
API with few having minor or
major issues in connecting
All pages/components connect
and retrieve data from the API.
Some potential issues remain
due to error handling.
All pages connect and retrieve
data from the API, with
appropriate error handling in
place for unusual situations
such as timeouts etc.
This document is for Coventry University students for their own use in completing their assessed work for this module and should not be passed to third
parties or posted on any website. Any infringements of this rule should be reported to facultyregistry.eec@coventry.ac.uk.
Front-end code
Architecture
5%
No code
provided or no
attempt at
architecture.
An attempt for a frontend
code architecture was
made, but it is not
working properly, or it is
mostly incomplete
Code architecture is not
complete, with major flaws in
some pages. Attempts to use
React components for major
application parts only.
Generally good architecture that
needs improving in some
places. React components have
a clear hierarchy but could be
broken down further.
Good architecture with some flow in
the design of the code. Good choice
of component hierarchy, use of
raising state or other appropriate
methods for sharing app data.
Clear architecture and component
hierarchy enabling effective
communication between all
interacting components.
Design and UX
10%
No CSS used
at all. Unusable
interface.
Attempt to lay out unstyled
or minimally
styled components but
app is convoluted and
may not display
correctly.
A CSS framework has been
chosen to enable consistent
formatting and layout. However,
this has only been minimally
implemented and better
component choices could have
been made. May have glitches
in the interface such as having
to refresh to update.
A responsive layout with
appropriate use of a CSS
framework to style components
in appropriate ways. Generally
good UX. May have minor
issues in navigating or receiving
instant feedback. Some controls
are unintuitive.
Sophisticated layout and design
reflecting a well-thought-out
application. Good UX, good
navigation, may still have minor
issues in interacting with controls
but generally smooth.
Effective design with advanced
elements such as theming. Design
is fully accessible and would
work well on desktop or mobile.
Very well designed UX smooth
navigation, instant feedback,
quality interface
Front-end Code
and testing 10%
No code
supplied. No
test code
supplied.
An attempt has been
made to write code to
implement some of the
basic functionality
although this may not
be successful. No
testing.
Working code base showing
the application of basic
programming principles.
Code may contain linting
errors and warnings. No or
limited testing.
Well written code with
inconsistencies in some
places. Some code
duplication. Would benefit
from mild refactoring. Error
handling is present but may
have holes. Validation is
present but may not cover all
possible issues.
The code is modular, follows a
consistent style, and includes full
or close to full exceptionhandling.
Data are thoroughly
validated before passing to the
API layer or to LocalStorage.
Some tests are defined but could
be more extensive.
The SPA demonstrates a wide
range of appropriate language
constructs including clear
modular structure and use of
abstract design patterns or
paradigms such as functional
programming. Concise easily
maintainable code. Wide range
of automated tests defined.
304CEM Grading Rubric for Full Stack Technology Report (20%)
0 1 2 3 4 5
6-8 Resource
Summaries and
their Relevance
to the Client’s
Development
Team 15%
No
attempt
Attempt to
summarise resources
but selections are
irrelevant, too
complex, or were
misunderstood.
Short summaries with some
indication of relevance to
the Client’s development
team. No concrete examples
of how the key points from
the resources will impact the
Concise summaries of interesting
and/or relevant resources showing
some understanding of the wider full
stack development ecosystem and
how the developed application fits in
to it, with some reasonable
Relevant resources identified.
Clear summary of each resource
including accurate evaluation of
key points. Good reflection on how
these points are likely to affect the
client team as they build new