- fork this repository
- write all of your code in a directory named
lab-#; +<your name>e.g.lab10-amanda - push to your repository
- submit a pull request to this repository
- submit a link to your PR in canvas
Build an api that creates and saves individual tasks. Think of tasks like:
- "Take Cat to Vet"
- "Eat Ice Cream", etc...
Build another API Controller that associates those tasks with list
- Monday's Tasks
- Weekend Activities
- List of Procrastination
- Use Postman or Fiddler to test your connections
- Have the Create/Read/Update/Delete commands for both Controllers
- Have a Database table for both of your tasks and lists
- use asyncrounous programming (async...await)
- Deploy your applicaiton to Azure
- Include Model Binding and Validation.
- be sure to check for Model State
- Remember about routing (hint: /api/[controller]), and constraint tokens {int:id} above any actions
A README is a module consumer's first -- and maybe only -- look into your creation. The consumer wants a module to fulfill their need, so you must explain exactly what need your module fills, and how effectively it does so.
Your job is to
- tell them what it is (with context)
- show them what it looks like in action
- show them how they use it
- tell them any other relevant details 5 Include a link to your deployed app in your Readme
This is your job. It's up to the module creator to prove that their work is a shining gem in the sea of slipshod modules. Since so many developers' eyes will find their way to your README before anything else, quality here is your public-facing measure of your work.
Refer to the sample-README in the class repo for an example.
-
7pts: Program meets all requirements described in Lab directions
-
3pts: Code meets industry standards
-
Readme.md and unit tests required for submission. Missing readme document and tests will result in a best score of 2/10
-
Program must build sucessfully and tests MUST be passing