The applications within a system are carved out based on their business responsibilities.

Similarly, the application's API should represent that business logic as well. The exposed API represents the business use cases a certain application comprises. This implies that a business domain expert can, without any further technical knowledge, identify the exposed business use cases from an API.

The business use cases are ideally offered in clear, lean interfaces. Invoking a use case should not require more technically-motivated communication steps or details than being part of the business logic. For example, if the create a car use case could be invoked as a single operation, the API of the car manufacture application should not require multiple invocations providing technical details.

An API should abstract the business logic in a clear, lean interface.

The API should therefore be decoupled from the application's implementation. The interface implementation should be independent from the chosen technology. This also implies that a communication format is chosen that doesn't set many constraints on the used technology.

It therefore makes sense to prefer technology that sets on standard protocols such as HTTP. It's more likely that engineer have knowledge in commonly used protocols, as that are supported by various technologies and tools. Creating application interfaces in HTTP web services allows clients to be developed in every technology that supports HTTP.

Abstracting the business logic in clear, lean interfaces that use standard protocols also enables change in used implementations, technologies, and platforms. Java Enterprise applications that only expose HTTP services could replace their technology with other implementations, without requiring dependent clients to change.