API endpoints are usually found in an API’s documentation, which is where developers put API information such as what type of requests an API will accept and how requests should be formatted. Ideally, this documentation also includes a list of all available API endpoints and a short description of their functionalities.

In a REST API (a software architectural style frequently used for web applications) context, the process looks like this:

The process starts when an API client sends a resource request (API call) to the corresponding API endpoint. Endpoints are accessed by using HTTP request methods such as POST, GET, PUT, PATCH and DELETE. These methods indicate the action that the client is looking to take on the specified resource.

For example, if a client is looking to retrieve a list of Olympic medal totals for a certain year from the hypothetical database Olympicfacts.com, a GET request is sent to the following endpoint URL: 

https://api.olympicfacts.com/v1/{year}

This request would return a list of Olympic medal totals by country. (v1 in our hypothetical endpoint indicates the version of the API, a common practice in API versioning.) If the client wanted a total for a specific country in a given year, an identifier would be added to the base URL: 

https://api.olympicfacts.com/v1/year/{id}

In this example, the identifier {id} is used to indicate which country the client is looking to receive information about.

In addition, a request might include:

• Headers: Headers can provide additional information about the request, such as an Accept header that specifies accepted media types
  
  
• Parameters: Query parameters can be added to the base URL or in the request body to further filter search criteria or add other specifications.
  
  
• Request body: A request body includes the data needed to create or modify a resource. For example, if the request is to create a new blog (POST request), the content of the new blog would be included in the request body.
  

Once the server authenticates the request and validates the input, it retrieves the requested data and returns the response to the client. Many organizations use API gateways to execute these functions and manage API traffic flow.

Key to any good API design is the testing phase. Modern applications often use APIs to integrate functions from other software, or are built by using microservices architectures (which rely on APIs for communication between disparate services). Testing API endpoints is essential to ensuring reliability.

There are both manual testing options for APIs and testing options that use automation, as well as numerous testing tools and platforms (both open source and propriety) that enterprises can use.

Manual API endpoint testing can be slower and less efficient, but also more precise and customized to specific use cases. Functional testing would be to simply send a request from an application to ensure that the correct response is given. In a social media example, this might mean sending a request for a new post by a particular user and checking to make sure that the returned post is indeed the correct one.

Other types of manual testing involve: 

• sending many requests all at once to see how the server handles request load
  
  
• checking to see that the API properly integrates with other services
  
  
• determining the speed and response time of a given request
  
  
• intentionally supplying an invalid request to check that the correct error message is returned

Automated testing done through an API management platform can deliver several advantages:

• reduces the possibility of human error
  
  
• is more efficient in checking the validity of multiple API endpoints
  
  
• can improve testing speed and potentially reduce costs in the long run once automated testing systems are established (saving on employee time, for example)
  
  
• Aligns testing along uniform protocols, standards and permissions

In general, each should return the intended response, in terms of format, data returned and status code.

Because API endpoints provide a way for both internal and external applications and systems to access and integrate data, they also present a potential entry points for bad actors. Distributed denial of service (DDoS) attacks can use legitimate requests but in absurd quantities to flood a server. Other types of attacks might attempt to use API endpoints to extract more information than the client is authorized to receive or use API endpoints to install malware or malicious code.

There are several ways that an organization can maintain the security of its API endpoints and overall API security, including:

API resources are datasets or objects that APIs provide. Resources vary based on the API in question, but content types include text, tables, source files, audio, video, images, users, products and much more.

An API endpoint is the specific location of those resources on a server. It is a point of contact between an API client and server, where API calls are directed.

Think of a business listing for a store. The listing provides the location of the store (endpoint) and how to contact it to request information such as store hours and product inventory (resources.)