## CRUD
describe what each group of status code represents:
These are informational status codes; they usually tell the client that the header part of the request has been received and the server will try to comply with a transmission demand of the client. Like using a different protocol or telling the client that its request will fail before they start sending the body.
These are the success codes. They tell the client that its request was accepted. In case of asynchronous processing of a request (202), this doesn’t mean the request was successfully processed only that it met all validation requirements at the time of sending.
These are redirection codes. They tell the client that the resource they are requesting isn’t available at the expected location anymore. This can have multiple reasons, be temporary or permanent, but the client has to issue a request to the new location.
These are the client error codes. They are all about invalid requests a client sent to a server. There are several causes to this, timeouts, wrong URI, missing authentication, etc. A client is sending incorrect input and should confirm the input parameters are correct before retrying the request.
These are the server error codes. Often they indicate problems with overwhelmed servers or unreachable servers behind proxies, but sometimes they can be directly related to client requests that trigger error exceptions on the server. These errors can be temporary or permanent. Usually it’s best for the client to retry the same request.
204 No Content is not terribly useful as a response code for a browser (although according to the HTTP spec browsers do need to understand it as a ‘don’t change the view’ response code). 204 No Content is however, very useful for ajax web services which may want to indicate success without having to return something. (Especially in cases like DELETE or POSTs that don’t require feedback). The answer, therefore, to your question is use 404 in your case. 204 is a specialized reponse code that you shouldn’t often return to a browser in response to a GET.
The other response codes that are even less appropriate than 204 and 404:
200 should be returned with the body of whatever you successfully fetched. Not appropriate when the entity you’re fetching doesn’t exist. 202 is used when the server has begun work on an object but the object isn’t fully ready yet. Certainly not the case here. You haven’t begun, nor will you begin, construction of user 9 in response to a GET request. That breaks all sorts of rules. 400 is used in response to a poorly formatted HTTP request (for instance malformed http headers, incorrectly ordered segments, etc). This will almost certainly be handled by whatever framework you’re using. You shouldn’t have to deal with this unless you’re writing your own server from scratch. Edit: Newer RFCs now allow for 400 to be used for semantically invalid requests.
The HTTP 403 Forbidden client error status response code indicates that the server understood the request but refuses to authorize it.
This status is similar to 401, but in this case, re-authenticating will make no difference. The access is permanently forbidden and tied to the application logic, such as insufficient rights to a resource.
Middleware is software that provides common services and capabilities to applications outside of what’s offered by the operating system. Data management, application services, messaging, authentication, and API management are all commonly handled by middleware.
Middleware helps developers build applications more efficiently. It acts like the connective tissue between applications, data, and users.
For organizations with multi-cloud and containerized environments, middleware can make it cost-effective to develop and run applications at scale.
The express.json() function is a built-in middleware function in Express. It parses incoming requests with JSON payloads and is based on body-parser.