When a mobile app shows your profile or a website loads a list of products, the interface often needs data from another service. An API defines how software can make that request and what kind of response it should expect. It is a contract between systems, not just a URL.
A request asks for a specific operation
An API endpoint identifies a resource or operation. A client might send a GET request to retrieve a profile, or a POST request to submit a new order. The request can include headers, parameters and—when appropriate—a body containing structured data such as JSON. The server processes the request and returns a response.
Responses include both data and status
A response usually contains a status code and may contain data. A successful response can include the requested record; an error response might indicate that the resource was not found, the caller is not authorised or the server could not complete the request. Clients should handle these outcomes explicitly instead of assuming every request succeeds.
Authentication is not the same as authorisation
Authentication establishes who or what is making a request. Authorisation determines what that caller is allowed to do. An API needs both appropriate access controls and careful handling of credentials. Sensitive keys should not be embedded in a public app, and every request should use an encrypted connection.
Design the contract for change
A useful API is consistent about naming, data formats, validation and errors. Documentation helps other developers use it correctly. As products evolve, changes should be introduced in a way that existing clients can handle—through compatible additions, clear deprecation periods or a deliberately versioned interface.
Good API design makes a product feel dependable because the website, app and server agree on how information moves. Clear contracts and thoughtful error handling make that coordination easier to build and maintain.
Source: MDN Web Docs
Questions or corrections? Write to contact@welkdock.com. Back to the Blog.
