100 - Informational codes that indicate that the server has received the client’s request and will continue processing it. These codes are used to provide feedback during the early stages of a request. 200 - Success codes that indicate that the client’s request was successfully received, understood, and processed by the server. These codes inform the client that everything went well. 300- Redirection codes that indicate that the requested resource is not available at the expected location and the client needs to take further action, such as making a new request to a different location. 400- Client error codes that indicate that the client’s request was invalid or could not be fulfilled by the server. These codes typically indicate issues like incorrect input, missing authentication, or a timeout. 500-Something is wrong in the server. Server error codes that indicate that the server encountered an error while processing the client’s request. These codes usually indicate temporary or permanent issues with the server, such as being overloaded or unreachable.
Status code 202: This status code, “Accepted,” is typically used for asynchronous processing. It indicates that the client’s request was valid and has been accepted by the server, but the processing of the request will happen at a later time.
Status code 308: This status code, “Permanent Redirect,” is used to inform the client that the requested resource has permanently moved to a new URL. The client should update its request to use the new URL for future access to the resource.
If an update doesn’t return data to a client, the appropriate code to use is 204 No Content. This status code indicates that the server successfully processed the request, but there is no content to return in the response.
If a resource used to exist but no longer does, the appropriate code to use is 410 Gone. This status code indicates that the resource is gone and will not be available again in the future.
The ‘Forbidden’ status code, 403 Forbidden, indicates that the client does not have the necessary permissions to access the requested resource. It is different from a 401 Unauthorized status code, which indicates that the client needs to provide valid credentials for access.
It is considered a best practice to store sensitive information, such as database connection strings, passwords, and API keys, in environment variables rather than hard-coding them into the source code. By storing the MongoDB database string in the .env file, you separate the configuration from the code, making it easier to manage and maintain. This approach also helps to protect sensitive information from being exposed if the source code is accidentally shared or if the project is hosted on a version control system.
Middleware refers to a piece of code that sits between the request and response objects in an application. It acts as a bridge, intercepting incoming requests, performing certain actions or transformations, and passing the request along to the next middleware or final request handler.
Middleware can be used for various purposes, such as logging, authentication, authorization, error handling, data parsing, and more. It allows developers to modularize their application logic and apply common functionalities across multiple routes or endpoints without duplicating code.
In the context of an Express.js application, app.use(express.json()) is middleware that parses incoming request bodies containing JSON data. It enables the server to handle JSON payloads sent by clients and transforms them into JavaScript objects, making it easier to work with the data within the application.
By including app.use(express.json()) in the application setup, you ensure that the middleware is applied to all routes, allowing the server to automatically parse JSON data in the request body.
For example, if you have a route defined as /users/:id, it means that the route expects a URL like /users/123, where 123 can be any value, and it will be captured and accessible within the route handler as req.params.id. This allows you to dynamically handle requests for specific resources based on their identifiers, such as retrieving a user with a specific ID from a database.
PUT: The PUT method is used to completely replace an existing resource with a new representation. When sending a PUT request, the entire resource is typically included in the request payload, and the server replaces the existing resource with the provided data. If a resource with the same identifier already exists, it is overwritten. PUT is considered an idempotent operation, meaning that sending the same request multiple times should have the same effect as sending it once.
PATCH: The PATCH method is used to partially update an existing resource. Unlike PUT, which replaces the entire resource, PATCH allows you to send only the changes or updates that need to be applied. The server then applies the provided changes to the resource, modifying only the specified fields or properties. PATCH requests are not necessarily idempotent, as multiple identical requests may have different effects depending on the initial state of the resource.
The default property
Something is wrong with the internal server.
200 means successful request, 201 means successful creation.