首页 > > 详细

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

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%)

联系我们 - QQ: 99515681 微信:codinghelp
程序辅导网!