基于HTTP的微服务是否必须采用REST？计算型微服务架构咨询

Absolutely! You’re not alone in this dilemma—REST’s emphasis on noun-based resources works great for services that manage persistent data, but it’s far from the only valid way to design HTTP APIs, especially for services like yours that exist purely to execute computations and return results.

Here’s why and how to approach it: #

• Embrace action-oriented endpoints
  Since your service doesn’t manage resources (no stored data like orders or users), there’s no need to force noun-based paths. Instead, use clear, verb-driven endpoints that describe the computation being performed. For example:

  • POST /calculate/order-pricing (takes order details, calls other services, returns computed price)
  • POST /compute/metric-summary (aggregates data from backend services, returns calculated metrics)
    The POST method is ideal here because it’s designed for non-idempotent actions (even if input is the same, external service changes could alter results) and allows you to send all necessary input data in the request body (avoiding long, messy URLs with GET parameters).

• Keep responses focused on results
  Unlike REST APIs that typically return representations of resources, your responses can directly return the computed output as JSON (or another format). For example, a successful call to /calculate/order-pricing might return:

  {
    "basePrice": 99.99,
    "tax": 8.99,
    "discount": 10.00,
    "finalTotal": 98.98
  }
  

  No need to wrap this in a "resource" object or include unnecessary fields like id or createdAt—just the data consumers need.

• Stick to HTTP semantics where it makes sense
  Even though you’re not following strict REST, you should still respect HTTP method meanings:

  • Use POST for computations that might have side effects (like triggering calls to other services) or non-idempotent results.
  • If your computation is fully idempotent (same input always gives same output) and inputs are small enough for a URL, you could use GET (e.g., GET /calculate/tax?amount=99.99&region=CA), but POST is safer for most complex calculation scenarios.
  • Use appropriate status codes: 200 OK for successful results, 400 Bad Request for invalid input, 503 Service Unavailable if dependent microservices are down, etc.

• Don’t feel pressured to "force REST"
  REST is a powerful architecture style, but it’s not a one-size-fits-all solution. Many well-known APIs (from cloud providers to payment gateways) use action-oriented HTTP endpoints for use cases where resource management isn’t the core goal. Your service’s purpose is to compute and return results—designing an API that directly reflects that will make it more intuitive for consumers to use.

内容的提问来源于stack exchange，提问作者François-David Lessard