I'm having trouble finding an answer for this when I search variants of my question. A use case I'm thinking of is a client makes a GET request to API server A for some data, but in order to provide that data it has to make a request to API server B. For whatever reason the endpoint at B is a POST endpoint (let's say even though it's just fetching data it needs a payload body and so they decided to make it a POST request).

Should the endpoint in API server A be converted to a POST endpoint since it makes a POST request? Or should the fact that the POST endpoint is in a separate API server not concern the design of endpoint A?

  • Is the GET request to server A doing anything else, or is it just doing a POST request to server B? If not, why have the GET request in the first place? Commented Jan 14, 2020 at 16:25
  • 2
    "Or should the fact that the POST endpoint is in a separate API server not concern the design of endpoint A" - exactly; the API on A is geared towards the services that A provides, and towards the needs of its clients (it's the abstraction/encapsulation principle, but on the inter-process level). Behind the API, A can do whatever it wants, the client should have no knowledge of that. 1/2 Commented Jan 14, 2020 at 16:41
  • 1
    That said, there are differences compared to local objects; you don't want to have too many hops (you don't want a long chain of services calling each other remotely); that might work well in a development environment, but in production, you may encounter problems with compounding latency, salability, etc. So limit the amount of indirect calls over remote APIs to some small number (e.g., 1 or 2 levels of indirection), and design service interfaces to be coarse grained (less calls, transfer data in bulk when needed). 2/2 Commented Jan 14, 2020 at 16:41

1 Answer 1


GET defines the semantics of the request. RFC 7231

The request method token is the primary source of request semantics; it indicates the purpose for which the client has made this request and what is expected by the client as a successful result.

In the case of GET, one of the important constraints is that the semantics are safe

Request methods are considered "safe" if their defined semantics are essentially read-only; i.e., the client does not request, and does not expect, any state change on the origin server as a result of applying a safe method to a target resource.

Note that this is a constraint on semantics, which is to say what the message means. What you do with a message that means GET is entirely up to you.

The fact that your server fetches data via POST is purely an implementation detail, just as it would be if we were using SOAP, or a GraphQL, or SQL, or fopen(), or....

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.