Which API design pattern is right for my project?

{
  "_meta": {
    "schema": "https://www.drawdecisiontree.com/decision-dag.schema.json",
    "source": "https://www.drawdecisiontree.com",
    "description": "DrawDecisionTree.com is a free tool for building, sharing, and embedding interactive decision trees. This file is the machine-readable export of a published decision tree. The `dsl` field contains the original source in the Decision DAG DSL; the `dag` schema is documented at the URL in `schema` above.",
    "links": {
      "interactive": "https://www.drawdecisiontree.com/t/ma-operating-system/api-design.html",
      "embed": "https://www.drawdecisiontree.com/embed/path/ma-operating-system/api-design",
      "dsl_reference": "https://www.drawdecisiontree.com/decision-tree-dsl-reference.html",
      "guides": "https://www.drawdecisiontree.com/guides",
      "schema_docs": "https://www.drawdecisiontree.com/decision-dag.schema.json",
      "author_trees": "https://www.drawdecisiontree.com/trees/ma-operating-system"
    },
    "generated_at": "2026-05-29T12:05:39.241Z"
  },
  "author": {
    "handle": "ma-operating-system",
    "first_name": "M&AOperatingSystem",
    "last_name": null,
    "avatar_url": "4d26d57f-9751-4220-beae-98346f806aa8/avatar-1777319673762.svg",
    "display_name": "M&AOperatingSystem"
  },
  "file": {
    "id": "d2b9534d-ce6e-40b4-9a75-b2991363db88",
    "name": "Which API design pattern is right for my project?",
    "public_slug": "api-design",
    "updated_at": "2026-05-29T00:33:08.447621+00:00",
    "url": "https://www.drawdecisiontree.com/t/ma-operating-system/api-design.html",
    "json_url": "https://www.drawdecisiontree.com/t/ma-operating-system/api-design/tree.json",
    "dsl_url": "https://www.drawdecisiontree.com/t/ma-operating-system/api-design/tree.dag"
  },
  "meta": {
    "description": "Determine the right API design style for your integration scenario.",
    "mode": "decision",
    "entry": "Q1",
    "tags": [],
    "image": null
  },
  "questions": [
    {
      "id": "Q1",
      "text": "Who are the primary consumers of this API?"
    },
    {
      "id": "Q2",
      "text": "Is low-latency real-time streaming required?"
    },
    {
      "id": "Q3",
      "text": "Does the client need fine-grained control over exactly which fields are fetched?"
    },
    {
      "id": "Q4",
      "text": "Is bidirectional communication (client push AND server push) needed?"
    },
    {
      "id": "Q5",
      "text": "Is strict contract-first API design with generated SDKs a priority?"
    }
  ],
  "outcomes": [
    {
      "id": "OUT_REST",
      "label": "REST (pragmatic)"
    },
    {
      "id": "OUT_REST_OPENAPI",
      "label": "REST + OpenAPI"
    },
    {
      "id": "OUT_GRAPHQL",
      "label": "GraphQL"
    },
    {
      "id": "OUT_GRPC",
      "label": "gRPC / Protocol Buffers"
    },
    {
      "id": "OUT_WEBSOCKET",
      "label": "WebSocket / Server-Sent Events"
    }
  ],
  "dsl": "dag: Which API design pattern is right for my project?\nversion: 1.0.0\ndescription: Determine the right API design style for your integration scenario.\nentry: Q1\n\nQ1: Who are the primary consumers of this API?\n  A: Internal services (backend-to-backend) -> Q2\n  B: Third-party developers / public         -> Q2\n  C: Mobile or browser clients               -> Q3\n\nQ2: Is low-latency real-time streaming required?\n  yes -> Q4\n  no  -> Q5\n\nQ3: Does the client need fine-grained control over exactly which fields are fetched?\n  yes -> [OUT_GRAPHQL]\n  no  -> Q5\n\nQ4: Is bidirectional communication (client push AND server push) needed?\n  yes -> [OUT_WEBSOCKET]\n  no  -> [OUT_GRPC]\n\nQ5: Is strict contract-first API design with generated SDKs a priority?\n  yes -> [OUT_REST_OPENAPI]\n  no  -> [OUT_REST]\n\n[OUT_REST]:        REST (pragmatic)\n  description: Standard HTTP verbs and JSON payloads. Best default choice for most CRUD-style service integrations.\n  code: API_REST\n\n[OUT_REST_OPENAPI]: REST + OpenAPI\n  description: REST with an OpenAPI 3.x spec-first workflow. Enables auto-generated SDKs, mocks, and documentation for public or partner APIs.\n  code: API_REST_OPENAPI\n\n[OUT_GRAPHQL]:     GraphQL\n  description: Flexible query language allowing clients to request exactly the data they need. Ideal for complex, rapidly evolving frontend data requirements.\n  code: API_GRAPHQL\n\n[OUT_GRPC]:        gRPC / Protocol Buffers\n  description: High-performance binary RPC with strongly typed contracts. Best for internal microservice communication where throughput and latency matter.\n  code: API_GRPC\n\n[OUT_WEBSOCKET]:   WebSocket / Server-Sent Events\n  description: Full-duplex or server-push protocol. Use for chat, live dashboards, collaborative editing, or any scenario requiring real-time bidirectional messaging.\n  code: API_WEBSOCKET\n\nroutes:\n  Q1=A, Q2=no, Q5=no -> [OUT_REST]\n  Q1=A, Q2=no, Q5=yes -> [OUT_REST_OPENAPI]\n  Q1=A, Q2=yes, Q4=no -> [OUT_GRPC]\n  Q1=A, Q2=yes, Q4=yes -> [OUT_WEBSOCKET]\n  Q1=B, Q2=no, Q5=no -> [OUT_REST]\n  Q1=B, Q2=no, Q5=yes -> [OUT_REST_OPENAPI]\n  Q1=B, Q2=yes, Q4=no -> [OUT_GRPC]\n  Q1=B, Q2=yes, Q4=yes -> [OUT_WEBSOCKET]\n  Q1=C, Q3=yes -> [OUT_GRAPHQL]\n  Q1=C, Q3=no, Q5=no -> [OUT_REST]\n  Q1=C, Q3=no, Q5=yes -> [OUT_REST_OPENAPI]\n"
}