lboyer4 / color-catcher-backend Goto Github PK

Delete a palette off of a project
Delete the whole project

Change a palette
Change a project

Fix test for app.get '/api/v1/palettes/:id' now that we've added query params

In the README, developer should provide documentation on the API endpoints that can be hit. Here is a great example of in-depth documentation Pay attention to the information provided and the format that it’s presented in.

Some things you want to considering having in your API documentation:

Endpoints available (e.g. GET /api/v1/students, POST api/v1/students)
What parameters can be used in certain requests (e.g. For a POST request, what should be put in the request body?)
Sample responses from endpoints (What does the response object look like for a request?)
You can put your documentation in the README of your BYOB GitHub repository. Remember, improperly formatted information can make it very difficult to read even if it’s all accurate, so be sure to utilize markdown syntax styling/formatting (here is a markdown style cheatsheet).

Developer must use query params on at least one endpoint, which would allow the user to narrow down the nature of their request or filter their results. So for example, you may have an endpoint like:

GET api/v1/merchants?areacode=80202

Which would limit the results to merchants in the 80202 area code.

Example of implementations here: https://scotch.io/tutorials/use-expressjs-to-get-url-and-post-parameters

POST endpoint - for palette
POST endpoint - for project

Pseudocode out tests for each endpoint:
agreed to have this done by EOD 7/3/19

Sally: All project endpoints
Lauren: All palettes endpoints

Change inconsistencies in naming conventions to be all 'req' and 'res' or all 'request' and 'response'.

2 GET endpoints that serve up ALL of a single resource

Remove from all of backend code/clean up.

200/201: Success error status code

All endpoints need to be tested for happy AND sad paths.
You should assert that proper status codes are being returned as well as appropriate response data and error messages.
Please reference the server-side testing lesson to see the robustness and thoroughness of testing we are expecting.

404: Success error status code

If you have a critical server error, you should respond with

500: Internal Server Error

Your back-end will be deployed to Heroku, and we will set up continuous integration using the TravisCI tool. We will have a lesson where we deploy our BE applications using TravisCI and Heroku together at the end of Week 2.

2 GET endpoints that serve up a single record of a resource

422: Unprocessable Entity response code, If POST request fails to save an entity due to bad information being sent from the client, you should respond with 422