{
  "id": "019f4be1-e9dd-727e-a4d4-56d265731b14",
  "type": "post",
  "thread": [
    {
      "id": "019f4be1-e9dd-727e-a4d4-56d265731b14",
      "depth": 0,
      "author": "Michael Schmidt",
      "url": "https://vutuv.de/michael_schmidt/posts/019f4be1-e9dd-727e-a4d4-56d265731b14",
      "published_on": "2026-07-10",
      "body_markdown": "# HTTP hat eine neue Standard-Methode. Das erste Mal seit 16 Jahren.\n\nNach PATCH (2010) kommt jetzt QUERY dazu – frisch verabschiedet als RFC 10008. Sie schließt eine Lücke, die viele von uns über Jahre mit einem schlechten Kompromiss umschifft haben: Für komplexe Suchanfragen GET zu verwenden ist semantisch korrekt, aber unpraktisch (URL-Längenlimits, unübersichtliche Parameter). Also landet man bei POST – technisch machbar, aber eigentlich eine kleine Lüge gegenüber dem Protokoll, weil POST \"hier verändert sich etwas\" bedeutet, obwohl nur gelesen wird.\n\nQUERY verbindet jetzt beides: Request-Body wie POST, aber sicher und idempotent wie GET.\n\nIn unserem neuen Blogartikel gehen wir durch:\n\n* Was genau im RFC steht (inkl. dem neuen Accept-Query-Header)\n* Warum Caching bei QUERY komplizierter ist als bei GET\n* Den aktuellen Stand bei Browsern, Node.js, Spring & Co.\n* Konkrete Code-Beispiele für PHP und JavaScript\n\nFür alle, die APIs bauen oder Suchfunktionen entwickeln, lohnt sich ein Blick – auch wenn der produktive Einsatz sicher noch dauert.\n\nhttps://www.tagworx.net/ynews.php?cid=1&nid=39012",
      "author_username": "michael_schmidt",
      "in_reply_to_author": null,
      "in_reply_to_id": null
    },
    {
      "id": "019f8ddc-efc1-77ce-80ba-077ee3df1bac",
      "depth": 1,
      "author": "Alexander van der Steeg",
      "url": "https://vutuv.de/alexander_vds/posts/019f8ddc-efc1-77ce-80ba-077ee3df1bac",
      "published_on": "2026-07-23",
      "body_markdown": "Top Artikel, den nehmen wir auch mal auf, da wir dies nach und nach in den APIs berücksichtigen müssen!",
      "author_username": "alexander_vds",
      "in_reply_to_author": "Michael Schmidt",
      "in_reply_to_id": "019f4be1-e9dd-727e-a4d4-56d265731b14"
    }
  ],
  "description": "# HTTP hat eine neue Standard-Methode. Das erste Mal seit 16 Jahren.",
  "title": "Michael Schmidt · 2026-07-10",
  "author": {
    "name": "Michael Schmidt",
    "username": "michael_schmidt",
    "url": "https://vutuv.de/michael_schmidt"
  },
  "replies": [
    {
      "author": "Alexander van der Steeg",
      "url": "https://vutuv.de/alexander_vds/posts/019f8ddc-efc1-77ce-80ba-077ee3df1bac",
      "published_on": "2026-07-23",
      "body_markdown": "Top Artikel, den nehmen wir auch mal auf, da wir dies nach und nach in den APIs berücksichtigen müssen!",
      "author_username": "alexander_vds"
    }
  ],
  "url": "https://vutuv.de/michael_schmidt/posts/019f4be1-e9dd-727e-a4d4-56d265731b14",
  "formats": {
    "json": "https://vutuv.de/michael_schmidt/posts/019f4be1-e9dd-727e-a4d4-56d265731b14.json",
    "text": "https://vutuv.de/michael_schmidt/posts/019f4be1-e9dd-727e-a4d4-56d265731b14.txt",
    "markdown": "https://vutuv.de/michael_schmidt/posts/019f4be1-e9dd-727e-a4d4-56d265731b14.md",
    "xml": "https://vutuv.de/michael_schmidt/posts/019f4be1-e9dd-727e-a4d4-56d265731b14.xml"
  },
  "tags": [
    "http",
    "query",
    "Methode",
    "RFC",
    "10008"
  ],
  "in_reply_to": null,
  "like_count": 3,
  "generated_at": "2026-07-25T02:38:29Z",
  "schema_version": 3,
  "published_on": "2026-07-10",
  "images": [
    {
      "width": 1716,
      "alt": "",
      "height": 1240,
      "urls": {
        "thumb": "https://vutuv.de/post_images/sURDCJuOmjtXgO5j8UUHBg/thumb.avif",
        "feed": "https://vutuv.de/post_images/sURDCJuOmjtXgO5j8UUHBg/feed.avif",
        "large": "https://vutuv.de/post_images/sURDCJuOmjtXgO5j8UUHBg/large.avif"
      }
    }
  ],
  "review": null,
  "reply_count": 1,
  "body_markdown": "# HTTP hat eine neue Standard-Methode. Das erste Mal seit 16 Jahren.\n\nNach PATCH (2010) kommt jetzt QUERY dazu – frisch verabschiedet als RFC 10008. Sie schließt eine Lücke, die viele von uns über Jahre mit einem schlechten Kompromiss umschifft haben: Für komplexe Suchanfragen GET zu verwenden ist semantisch korrekt, aber unpraktisch (URL-Längenlimits, unübersichtliche Parameter). Also landet man bei POST – technisch machbar, aber eigentlich eine kleine Lüge gegenüber dem Protokoll, weil POST \"hier verändert sich etwas\" bedeutet, obwohl nur gelesen wird.\n\nQUERY verbindet jetzt beides: Request-Body wie POST, aber sicher und idempotent wie GET.\n\nIn unserem neuen Blogartikel gehen wir durch:\n\n* Was genau im RFC steht (inkl. dem neuen Accept-Query-Header)\n* Warum Caching bei QUERY komplizierter ist als bei GET\n* Den aktuellen Stand bei Browsern, Node.js, Spring & Co.\n* Konkrete Code-Beispiele für PHP und JavaScript\n\nFür alle, die APIs bauen oder Suchfunktionen entwickeln, lohnt sich ein Blick – auch wenn der produktive Einsatz sicher noch dauert.\n\nhttps://www.tagworx.net/ynews.php?cid=1&nid=39012",
  "bookmark_count": 0,
  "fediverse_reaction_count": 0,
  "repost_count": 0,
  "thread_truncated": false
}