100-range: Informational codes confiriming receipt of request.
200-range: Indicate an accepted request, like 204, which represents a confirmation of updates that do not themselves return to the clien. However, some codes don’t necessarily indicate complete processing (like 202, which indicates asynchronous processing that was initially validated; 201, which indicates a successful creation of an object, and 200, which indicates a generic “successful request” status)
300-range: Indicate redirection to another resource (like 308, which indicates the permanent redirection to another resource— useful if hosting or server routes have changed)
400-range: Client error codes. These represent bad requests on client end (like 410, which indicates that the resource was formerly located at that route but currently has no associated redirect, or 403, which indicates lack of client permissions for the resource)
500-range: Server error codes (indicate unreachable or overtaxed server, or unhandled exceptions)
process.env placeholder in code allows for functioning in both the local and deployed settings.
Middleware programs and libraries facilitate easier establishment and coding of a server and the related files*app.use(express.json()) allows the server to properly parse files in the .json format (common for data sets)
Adding '/:id' to a route adds parameters that can be passed into the URL.
When updating limited fields of data with a request, PATCH should be used (as opposed to PUT for replacement of all fileds within the relevant set of data)
The constructor function can be used to establish the default data schema: when defining the data type for different properties, (“properties of properties”) set a key of default with the required default value.
Apparently the Internet Assigned Numbers Authority maintains the standardized HTTP Status Code Registry, but what is the process for new accepted values? Do shifts in the sorts of data use and traffic lead to lobbying for new consistent code messaging for some statuses or issues?