ಹೊಸ HTTP QUERY ವಿಧಾನ: Body ಯೊಂದಿಗೆ GET Request

HTTP 1996 ರಿಂದ ವೆಬ್‌ನ ಬೆನ್ನೆಲುಬಾಗಿದೆ. ಸುಮಾರು ಮೂರು ದಶಕಗಳಲ್ಲಿ, ವಿಧಾನಗಳ ಮುಖ್ಯ ಗುಂಪು — GET, POST, PUT, DELETE, PATCH — ಹೆಚ್ಚಾಗಿ ಬದಲಾಗಲಿಲ್ಲ. ಡೆವಲಪರ್‌ಗಳು ಅವುಗಳ ಆಧಾರದ ಮೇಲೆಯೇ REST API ಗಳ ದೊಡ್ಡ ಸಾಮ್ರಾಜ್ಯಗಳನ್ನೇ ನಿರ್ಮಿಸಿದರು. ಮತ್ತು ಹೆಚ್ಚಿನ ಬಳಕೆಯ ಸಂದರ್ಭಗಳಿಗೆ, ಅವು ಚೆನ್ನಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತವೆ.

ಆದರೆ ಅಲ್ಲೊಂದು ಕೊರತೆ ಇತ್ತು. ಪ್ರತಿಯೊಬ್ಬ API ಡೆವಲಪರ್ ಎಂದಾದರೂ ಎದುರಿಸಿರುವ ಒಂದು ರಚನಾತ್ಮಕ, ಕಿರಿಕಿರಿ ಉಂಟುಮಾಡುವ ಮತ್ತು ಕೆಲವೊಮ್ಮೆ ಅಪಾಯಕಾರಿ ಕೊರತೆ: ನೀವು ಡೇಟಾಗಾಗಿ ಹುಡುಕಬೇಕಾದಾಗ ಮತ್ತು ಆ ಹುಡುಕಾಟವೇ ಸಂಕೀರ್ಣವಾಗಿದ್ದಾಗ ನೀವು ಏನು ಮಾಡುತ್ತೀರಿ?

ಜುಲೈ 17, 2026 ರಂದು, ಆ ಕೊರತೆಗೆ ಅಂತಿಮವಾಗಿ ಅಧಿಕೃತ ಉತ್ತರ ಸಿಕ್ಕಿದೆ. ಜೂನ್ 15, 2026 ರಂದು ಪ್ರಮಾಣೀಕರಿಸಲ್ಪಟ್ಟ ಮತ್ತು RFC 9148 ನಲ್ಲಿ ಅಧಿಕೃತವಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸಲಾದ QUERY HTTP ವಿಧಾನವು ಬಹುಕಾಲದ ನಂತರ HTTP ವಿಧಾನಗಳ ಕುಟುಂಬಕ್ಕೆ ಸೇರ್ಪಡೆಯಾದ ಮೊದಲ ಹೊಸ ವಿಧಾನವಾಗಿದೆ. ಮತ್ತು ಇದು GET ಹಾಗೂ POST ಎಂದಿಗೂ ಸಂಪೂರ್ಣವಾಗಿ ಸ್ಪಷ್ಟವಾಗಿ ನಿರ್ವಹಿಸದ ನೈಜ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುತ್ತದೆ.

ಸಮಸ್ಯೆ: GET ಸಂಕೀರ್ಣ ಹುಡುಕಾಟಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ

GET ಡೇಟಾ ಹಿಂಪಡೆಯುವಿಕೆಯ ಪ್ರಮುಖ ಕೆಲಸಗಾರವಾಗಿದೆ. ನೀವು URL ಒಂದನ್ನು ಭೇಟಿ ಮಾಡುತ್ತೀರಿ, ಸರ್ವರ್ ನಿಮಗೆ ಡೇಟಾ ನೀಡುತ್ತದೆ. ಸರಳ, ಸ್ಪಷ್ಟ, cache ಮಾಡಬಹುದಾದದ್ದು. ನೇರವಾದ ಹುಡುಕಾಟಗಳಿಗೆ — "ನನಗೆ ಬಳಕೆದಾರ 42 ನೀಡಿ" ಅಥವಾ "ಪ್ರಕಟಿಸಲಾದ ಎಲ್ಲಾ ಪೋಸ್ಟ್‌ಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡಿ" — GET ಸೂಕ್ತವಾಗಿದೆ.

ಆದರೆ ಆಧುನಿಕ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಯಾವಾಗಲೂ ಸರಳ ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳುವುದಿಲ್ಲ.

ನೀವು ಅನಾಲಿಟಿಕ್ಸ್ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್ ನಿರ್ಮಿಸುತ್ತಿದ್ದೀರಿ ಎಂದು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ. ಒಬ್ಬ ಬಳಕೆದಾರರು ಹನ್ನೆರಡು ವಿಭಿನ್ನ ನಿಯತಾಂಕಗಳ ಮೂಲಕ ಫಿಲ್ಟರ್ ಮಾಡಲು ಬಯಸುತ್ತಾರೆ: ದಿನಾಂಕದ ಶ್ರೇಣಿಗಳು, ನೆಸ್ಟೆಡ್ ಭೌಗೋಳಿಕ ಪ್ರದೇಶಗಳು, ನಿರ್ದಿಷ್ಟ ಉತ್ಪನ್ನದ ವರ್ಗಗಳು, ಬೂಲಿಯನ್ ಲಾಜಿಕ್ ಹೊಂದಿರುವ ಬಳಕೆದಾರರ ವಿಭಾಗಗಳು ಮತ್ತು ಉಚಿತ-ಪಠ್ಯ ಹುಡುಕಾಟದ ಪ್ರಶ್ನೆ. ಆ ಫಿಲ್ಟರ್ ಸೆಟ್ ಸುಲಭವಾಗಿ 1,000 ಬೈಟ್‌ಗಳನ್ನು ಮೀರಬಹುದು.

ಇಲ್ಲಿಯೇ GET ವಿಫಲಗೊಳ್ಳುತ್ತದೆ. GET request ನಲ್ಲಿರುವ ಪ್ರತಿಯೊಂದೂ URL ನಲ್ಲಿರುತ್ತದೆ. ಮತ್ತು URL ಗಳಿಗೆ ಪ್ರಾಯೋಗಿಕ ಉದ್ದದ ಮಿತಿಗಳಿವೆ. ಬ್ರೌಸರ್‌ಗಳು ಅವುಗಳನ್ನು ಮಿತಿಗೊಳಿಸುತ್ತವೆ, ಪ್ರಾಕ್ಸಿಗಳು ಅವುಗಳನ್ನು ಕಡಿತಗೊಳಿಸುತ್ತವೆ, ಸರ್ವರ್‌ಗಳು ಅವುಗಳನ್ನು ತಿರಸ್ಕರಿಸುತ್ತವೆ. RFC 2616 ಸರ್ವರ್‌ಗಳು ಕನಿಷ್ಠ 8,000 ಬೈಟ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಶಿಫಾರಸು ಮಾಡುತ್ತದೆ, ಆದರೆ ಅನೇಕ ನೈಜ-ಪ್ರಪಂಚದ ನಿಯೋಜನೆಗಳು ಅದಕ್ಕಿಂತ ಮುಂಚಿತವಾಗಿಯೇ ವಿಫಲಗೊಳ್ಳುತ್ತವೆ.

ಇನ್ನೂ ಕೆಟ್ಟ ವಿಷಯವೆಂದರೆ, ಆ URL ನಿಯತಾಂಕಗಳು ಎಲ್ಲೆಡೆ ಲಾಗ್ ಆಗುತ್ತವೆ. ಬ್ರೌಸರ್ ಇತಿಹಾಸವು ಸಂಪೂರ್ಣ URL ಅನ್ನು ಸೆರೆಹಿಡಿಯುತ್ತದೆ. ಪ್ರಾಕ್ಸಿ ಸರ್ವರ್‌ಗಳು ಅದನ್ನು ಕ್ಯಾಶ್ ಮಾಡುತ್ತವೆ. ಸರ್ವರ್ ಪ್ರವೇಶ ಲಾಗ್‌ಗಳು ಅದನ್ನು ಸಂಗ್ರಹಿಸುತ್ತವೆ. ನಿಮ್ಮ ಹುಡುಕಾಟವು ಸೂಕ್ಷ್ಮ ಡೇಟಾವನ್ನು ಒಳಗೊಂಡಿದ್ದರೆ — ರೋಗಿಯ ID, ಸೋಷಿಯಲ್ ಸೆಕ್ಯುರಿಟಿ ಸಂಖ್ಯೆಯ ಭಾಗ, ಆಂತರಿಕ ಖಾತೆಯ ಉಲ್ಲೇಖ — ಆ ಮಾಹಿತಿಯು ಈಗ ನೀವು ನಿಯಂತ್ರಿಸದ ಬಹು ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ ಪ್ಲೇನ್ ಟೆಕ್ಸ್ಟ್ ರೂಪದಲ್ಲಿ ಕುಳಿತಿರುತ್ತದೆ.

ಇದು ಕೇವಲ ಸೈದ್ಧಾಂತಿಕ ಕಳಕಳಿಯಲ್ಲ. ಇದು ನಿಜವಾದ ಅನುಸರಣೆಯ (compliance) ತಲೆನೋವು.

ಸಮಸ್ಯೆ: POST ಎಂಬುದು ಸುಳ್ಳು

ಆದ್ದರಿಂದ ಡೆವಲಪರ್‌ಗಳು ಯಾವಾಗಲೂ ಮಾಡುವಂತೆಯೇ ಮಾಡುತ್ತಾರೆ — ಅವರು ಈ ಮಿತಿಯನ್ನು ದಾಟಲು ಹ್ಯಾಕ್ ಮಾಡುತ್ತಾರೆ. "ಕೇವಲ POST ಬಳಸಿ," ಎಂದು ಕೋಡ್ ಪರಿಶೀಲನೆಯಲ್ಲಿ ಯಾರೋ ಹೇಳುತ್ತಾರೆ. "ನೀವು POST request ನಲ್ಲಿ JSON body ಅನ್ನು ಇರಿಸಬಹುದು, ಮತ್ತು body URL ನಲ್ಲಿ ಸೇರುವುದಿಲ್ಲ."

ತಾಂತ್ರಿಕವಾಗಿ ನಿಜ. ಆದರೆ ಅರ್ಥಶಾಸ್ತ್ರದ ದೃಷ್ಟಿಯಿಂದ ತಪ್ಪು.

POST ಅನ್ನು ಡೇಟಾವನ್ನು ಮಾರ್ಪಡಿಸಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ. ಇದು ಸರ್ವರ್‌ಗೆ ಹೇಳುತ್ತದೆ: "ನಾನು ನಿಮಗೆ ಏನನ್ನೋ ಕಳುಹಿಸುತ್ತಿದ್ದೇನೆ — ಸಂಪನ್ಮೂಲವನ್ನು ರಚಿಸಿ, ಪ್ರಕ್ರಿಯೆಯನ್ನು ಪ್ರಚೋದಿಸಿ, ಸ್ಥಿತಿಯನ್ನು ಬದಲಾಯಿಸಿ." HTTP ವಿವರಣೆಗಳು ಅದನ್ನೇ ಹೇಳುತ್ತವೆ. ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್ ಫೈರ್‌ವಾಲ್‌ಗಳು ಅದನ್ನೇ ನಿರೀಕ್ಷಿಸುತ್ತವೆ. ಸರ್ವರ್ ಫ್ರೇಮ್‌ವರ್ಕ್‌ಗಳು ಅದನ್ನೇ ಊಹಿಸುತ್ತವೆ.

ನೀವು ಡೇಟಾವನ್ನು ಹುಡುಕಲು POST ಅನ್ನು ಬಳಸಿದಾಗ, ನೀವು ತಂತ್ರಜ್ಞಾನದ ಪ್ರತಿಯೊಂದು ಹಂತಕ್ಕೂ ಸುಳ್ಳು ಹೇಳುತ್ತಿದ್ದೀರಿ.

ಇದು ಕೇವಲ ತಾತ್ವಿಕ ಶುದ್ಧತೆಯ ವಿಷಯವಲ್ಲ. ಇದು ನಿಜವಾದ ಪರಿಣಾಮಗಳನ್ನು ಹೊಂದಿದೆ:

• ಕ್ಯಾಶಿಂಗ್ ಮುರಿಯುತ್ತದೆ. ಹೆಚ್ಚಿನ HTTP ಕ್ಯಾಶ್‌ಗಳು — CDN ಗಳು, ರಿವರ್ಸ್ ಪ್ರಾಕ್ಸಿಗಳು, ಬ್ರೌಸರ್ ಕ್ಯಾಶ್‌ಗಳು — ಡೀಫಾಲ್ಟ್ ಆಗಿ POST ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಕ್ಯಾಶ್ ಮಾಡುವುದಿಲ್ಲ, ಏಕೆಂದರೆ POST ಎಂದರೆ ಪ್ರತಿ ಬಾರಿಯೂ ಪ್ರತಿಕ್ರಿಯೆಯು ವಿಭಿನ್ನವಾಗಿರಬಹುದು (ಏಕೆಂದರೆ ಸರ್ವರ್ ಸ್ಥಿತಿ ಬದಲಾಗಿದೆ).
• ಆಕಸ್ಮಿಕ ಅಡ್ಡಪರಿಣಾಮಗಳು. ಕೆಲವು ಸರ್ವರ್ ಫ್ರೇಮ್‌ವರ್ಕ್‌ಗಳು ಮತ್ತು ಮಿಡಲ್‌ವೇರ್‌ಗಳು POST ಅನ್ನು ವಿಭಿನ್ನವಾಗಿ ಉಪಚರಿಸುತ್ತವೆ. ಅವು ಆಡಿಟ್ ಲಾಗ್‌ಗಳಿಗೆ ಬರೆಯಬಹುದು, ವೆಬ್‌ಹುಕ್‌ಗಳನ್ನು ಪ್ರಚೋದಿಸಬಹುದು ಅಥವಾ ವಿಭಿನ್ನ ರೇಟ್ ಲಿಮಿಟಿಂಗ್ ನಿಯಮಗಳನ್ನು ಅನ್ವಯಿಸಬಹುದು — ಎಲ್ಲವೂ ನಿಮ್ಮ "ಹುಡುಕಾಟ" ಎಂಡ್‌ಪಾಯಿಂಟ್ "ರಚನೆ" ಎಂಡ್‌ಪಾಯಿಂಟ್‌ನಂತೆ ಕಾಣುವ ಕಾರಣದಿಂದಾಗಿ.
• CSRF ಅಪಾಯವು ಹೆಚ್ಚಾಗುತ್ತದೆ. POST ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗಳು ವಿಭಿನ್ನ ಕ್ರಾಸ್-ಆರಿಜಿನ್ (cross-origin) ಭದ್ರತಾ ನಿಯಮಗಳನ್ನು ಹೊಂದಿರುತ್ತವೆ. POST ಬಳಸುವ ಹುಡುಕಾಟ ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗೆ ಈಗ GET ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗೆ ಅಗತ್ಯವಿಲ್ಲದ CSRF ರಕ್ಷಣೆಯ ಅಗತ್ಯವಿದೆ.
• ಮತ್ತೆ ಪ್ರಯತ್ನಿಸುವುದು ಅಪಾಯಕಾರಿಯಾಗುತ್ತದೆ. ಒಂದು ವಿನಂತಿಯು ಟೈಮ್‌ಔಟ್ ಆದರೆ, ಕ್ಲೈಂಟ್‌ಗಳು ಸುರಕ್ಷಿತವಾಗಿ GET ಅನ್ನು ಮತ್ತೆ ಪ್ರಯತ್ನಿಸಬಹುದು (ಇದು idempotent ಆಗಿದೆ). POST ಅನ್ನು ಮತ್ತೆ ಪ್ರಯತ್ನಿಸುವುದು ನಕಲಿ ದಾಖಲೆಗಳನ್ನು ರಚಿಸಬಹುದು — ಮತ್ತು ನಿಮ್ಮ "ಹುಡುಕಾಟ" ಎಂಡ್‌ಪಾಯಿಂಟ್ ಯಾವುದನ್ನೂ ರಚಿಸಬಾರದು.

ಈ ಅಸಮಂಜಸತೆಯು ವರ್ಷಗಳಿಂದ ಬಗ್‌ಗಳು, ಭದ್ರತಾ ದೋಷಗಳು ಮತ್ತು ವಾಸ್ತುಶಿಲ್ಪದ ಅಡಚಣೆಗಳಿಗೆ ಕಾರಣವಾಗಿದೆ. GraphQL, ತನ್ನ ಎಲ್ಲಾ ಸಾಮರ್ಥ್ಯಗಳ ನಡುವೆಯೂ, ಇದನ್ನು ಇನ್ನಷ್ಟು ಸಾಮಾನ್ಯಗೊಳಿಸಿತು — ಹೆಚ್ಚಿನ GraphQL ಅನುಷ್ಠಾನಗಳು ಪ್ರಶ್ನೆಗಳನ್ನು (queries) POST ವಿನಂತಿಗಳಾಗಿ ಕಳುಹಿಸುತ್ತವೆ, ಅಂದರೆ GraphQL API ನಲ್ಲಿನ ಪ್ರತಿಯೊಂದು ಓದುವ ಕಾರ್ಯಾಚರಣೆಯು (read operation) ಬರೆಯುವ ಕಾರ್ಯಾಚರಣೆಯ (write operation) ಅರ್ಥಶಾಸ್ತ್ರದ ಹೊರೆಯನ್ನು ಹೊಂದಿರುತ್ತದೆ.

QUERY ನ ಪ್ರವೇಶ: ಕೆಲಸಕ್ಕೆ ಸೂಕ್ತವಾದ ಸಾಧನ

QUERY ವಿಧಾನವು ನಿಖರವಾಗಿ ಅದು ಹೇಗೆ ಕೇಳಿಸುತ್ತದೆಯೋ ಹಾಗೆಯೇ ಇದೆ: body ಅನ್ನು ಬೆಂಬಲಿಸುವ GET request.

ಇದು ಏಕೆ ವಿಭಿನ್ನವಾಗಿದೆ ಎಂಬುದು ಇಲ್ಲಿದೆ:

ಇದು ಸುರಕ್ಷಿತ ಮತ್ತು ಓದಲು ಮಾತ್ರ (read-only) ಆಗಿದೆ. QUERY ವಿಧಾನವನ್ನು ಸುರಕ್ಷಿತ, idempotent ಕಾರ್ಯಾಚರಣೆ ಎಂದು ವ್ಯಾಖ್ಯಾನಿಸಲಾಗಿದೆ. ಸತತವಾಗಿ ಹತ್ತು ಬಾರಿ ಒಂದೇ QUERY request ಕಳುಹಿಸುವುದರಿಂದ ಸರ್ವರ್‌ನಲ್ಲಿ ಯಾವುದೇ ಅಡ್ಡಪರಿಣಾಮಗಳಿಲ್ಲದೆ ಒಂದೇ ರೀತಿಯ ಫಲಿತಾಂಶವನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ. ಯಾವುದೇ ಡೇಟಾ ರಚನೆಯಾಗುವುದಿಲ್ಲ, ಯಾವುದೇ ಸ್ಥಿತಿ ಬದಲಾಗುವುದಿಲ್ಲ, ಆಕಸ್ಮಿಕವಾಗಿ ಯಾವುದೇ ಆಡಿಟ್ ಟ್ರೇಲ್‌ಗಳು ಪ್ರಚೋದಿಸಲ್ಪಡುವುದಿಲ್ಲ.

ಇದು request body ಅನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ. POST ನಂತೆಯೇ, ನಿಮ್ಮ API ಬಳಸುವ ರಚನಾತ್ಮಕ ಡೇಟಾವನ್ನು — JSON, XML, ಅಥವಾ ಇನ್ನಾವುದನ್ನಾದರೂ — ನೀವು request body ನಲ್ಲಿ ಸೇರಿಸಬಹುದು. ನಿಮ್ಮ ಸಂಕೀರ್ಣ ಹುಡುಕಾಟ ಫಿಲ್ಟರ್‌ಗಳು, ನೆಸ್ಟೆಡ್ ಆಬ್ಜೆಕ್ಟ್‌ಗಳು ಮತ್ತು ಮಲ್ಟಿ-ಕಿಲೋಬೈಟ್ ಪೇಲೋಡ್‌ಗಳು ಸಂಪೂರ್ಣವಾಗಿ URL ನಿಂದ ಹೊರಗಿರುತ್ತವೆ.

ಇದು ಸ್ಪಷ್ಟ ಉದ್ದೇಶವನ್ನು ಸೂಚಿಸುತ್ತದೆ. ಸರ್ವರ್ QUERY ವಿನಂತಿಯನ್ನು ಸ್ವೀಕರಿಸಿದಾಗ, ಕ್ಲೈಂಟ್‌ಗೆ ಏನು ಬೇಕು ಎಂಬುದರ ಕುರಿತು ಯಾವುದೇ ಗೊಂದಲವಿರುವುದಿಲ್ಲ. ಅದು ಡೇಟಾವನ್ನು ಓದಲು ಬಯಸುತ್ತದೆ. ಅಷ್ಟೇ. ಈ POST ಹುಡುಕಾಟವೇ ಅಥವಾ ರಚನೆಯ ಕಾರ್ಯಾಚರಣೆಯೇ ಎಂದು ಸರ್ವರ್ ಊಹಿಸುವ ಅಗತ್ಯವಿಲ್ಲ.

ಇದು ಸ್ವಾಭಾವಿಕವಾಗಿ ಕ್ಯಾಶ್ ಮಾಡಬಹುದಾಗಿದೆ. POST ಪರಿಹಾರಗಳಂತಲ್ಲದೆ, QUERY ಸೂಕ್ತವಾದ ಕ್ಯಾಶಿಂಗ್ ನಿಯಮಗಳೊಂದಿಗೆ HTTP ಪ್ರೋಟೋಕಾಲ್ ಹಂತದಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಕ್ಯಾಶ್‌ಗಳು ಮತ್ತು CDN ಗಳು QUERY ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಕ್ಯಾಶ್ ಮಾಡಬಹುದು ಏಕೆಂದರೆ ಈ ವಿಧಾನವು ಸರ್ವರ್ ಸ್ಥಿತಿಯನ್ನು ಬದಲಾಯಿಸುವುದಿಲ್ಲ ಎಂದು ಸ್ಪಷ್ಟವಾಗಿ ಘೋಷಿಸುತ್ತದೆ — ಇದನ್ನು POST ಎಂದಿಗೂ ಖಾತರಿಪಡಿಸುವುದಿಲ್ಲ.

ಈ ಕೊನೆಯ ಅಂಶವನ್ನು ಒತ್ತು ನೀಡುವುದು ಯೋಗ್ಯವಾಗಿದೆ. GraphQL ಸಂಕೀರ್ಣ ಫಿಲ್ಟರಿಂಗ್ ಅನ್ನು ಸುಂದರವಾಗಿ ನಿರ್ವಹಿಸುತ್ತದೆ, ಆದರೆ ಇದು ಅಪ್ಲಿಕೇಶನ್ ಹಂತದಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಹೆಚ್ಚಿನ GraphQL ಪ್ರಶ್ನೆಗಳು POST ವಿನಂತಿಗಳಾಗಿ ಚಲಿಸುತ್ತವೆ, ಮತ್ತು ಸರ್ವರ್‌ಗಳು ಸಾಮಾನ್ಯವಾಗಿ POST ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಸ್ವಾಭಾವಿಕವಾಗಿ ಕ್ಯಾಶ್ ಮಾಡುವುದಿಲ್ಲ. QUERY ವಿಧಾನವು ಟ್ರಾನ್ಸ್‌ಪೋರ್ಟ್ ಹಂತದಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಅಂದರೆ HTTP ಮೂಲಸೌಕರ್ಯಗಳು — ಪ್ರಾಕ್ಸಿಗಳು, CDN ಗಳು, ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್‌ಗಳು — ವಿಶೇಷ ಅಪ್ಲಿಕೇಶನ್-ಮಟ್ಟದ ಕಾನ್ಫಿಗರೇಶನ್ ಇಲ್ಲದೆಯೇ ಕ್ಯಾಶಿಂಗ್‌ನಲ್ಲಿ ಭಾಗವಹಿಸಬಹುದು.

QUERY Request ಹೇಗೆ ಕಾಣುತ್ತದೆ

ನೀವು ಎಂದಾದರೂ HTTP request ಬರೆದಿದ್ದರೆ, ಇದು ಪರಿಚಿತವೆನಿಸುತ್ತದೆ:

QUERY /api/analytics/events HTTP/1.1
Host: api.example.com
Content-Type: application/json
Accept: application/json

{
  "dateRange": {
    "start": "2026-01-01",
    "end": "2026-06-30"
  },
  "filters": {
    "regions": ["us-west-2", "eu-central-1"],
    "eventTypes": ["purchase", "refund"],
    "minAmount": 50.00
  },
  "groupBy": ["region", "month"],
  "limit": 100
}

ಅಷ್ಟೇ. URL ಸ್ವಚ್ಛವಾಗಿರುತ್ತದೆ. Body ಎಲ್ಲಾ ಸಂಕೀರ್ಣತೆಯನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಮತ್ತು HTTP ಮೂಲಸೌಕರ್ಯದ ಪ್ರತಿಯೊಂದು ಭಾಗಕ್ಕೂ ಈ request ಒಂದು ಓದುವ ಕಾರ್ಯಾಚರಣೆ ಎಂದು ತಿಳಿದಿರುತ್ತದೆ.

ಭದ್ರತೆಯ ಕೋನ: ಹೊಸ ವಿಧಾನ, ಹೊಸ ದಾಳಿ ಮೇಲ್ಮೈ

ಇಲ್ಲಿ ವಿಷಯವು ಆಸಕ್ತಿದಾಯಕವಾಗುತ್ತದೆ — ಮತ್ತು ಕೊಂಚ ಭಯಾನಕವಾಗುತ್ತದೆ.

QUERY ವಿಧಾನವು ಸಂಕೀರ್ಣ ಓದುವಿಕೆಗಳಿಗಾಗಿ GET ಮತ್ತು POST ನ ರಚನಾತ್ಮಕ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುತ್ತದೆ. ಆದರೆ ವೆಬ್‌ನ ಮೂಲಸೌಕರ್ಯಕ್ಕೆ ಹೊಸ HTTP ವಿಧಾನವನ್ನು ಪರಿಚಯಿಸುವುದು ದಾಳಿಕೋರರಿಗೆ ಮತ್ತು ಭದ್ರತಾ ಸಂಶೋಧಕರಿಗೆ ಒಂದು ಪ್ರಮುಖ ಹೊಸ ಕ್ರೀಡಾಂಗಣವನ್ನು ತೆರೆಯುತ್ತದೆ.

ಕ್ಯಾಶಿಂಗ್ ಕಷ್ಟಕರವಾಗುತ್ತದೆ

QUERY ಕ್ಯಾಶ್ ಮಾಡಬಹುದಾಗಿದೆ, ಮತ್ತು ಇದು body ಅನ್ನು ಹೊಂದಿದೆ. ಈ ಸಂಯೋಜನೆಯು ಹೆಚ್ಚಿನ HTTP ಮೂಲಸೌಕರ್ಯಗಳಿಗೆ ಹೊಸದಾಗಿದೆ.

ಸಾಂಪ್ರದಾಯಿಕ ಕ್ಯಾಶಿಂಗ್ URL ಮತ್ತು ನಿರ್ದಿಷ್ಟ ಹೆಡರ್‌ಗಳನ್ನು ಕ್ಯಾಶ್ ಕೀ ಆಗಿ ಬಳಸುತ್ತದೆ. QUERY ನೊಂದಿಗೆ, ಸರ್ವರ್‌ಗಳು ಮತ್ತು ಪ್ರಾಕ್ಸಿಗಳು request body ಅನ್ನು ಸಹ ಕ್ಯಾಶ್ ಕೀ ಯಲ್ಲಿ ಸೇರಿಸಬೇಕು. ಒಂದು ವೇಳೆ ಕ್ಯಾಶ್ ಅನುಷ್ಠಾನವು ಇದನ್ನು ತಪ್ಪಾಗಿ ನಿರ್ವಹಿಸಿದರೆ — ಉದಾಹರಣೆಗೆ ಅದು ಕೇವಲ URL ಅನ್ನು ಕೀ ಯಾಗಿ ಬಳಸಿ body ಅನ್ನು ನಿರ್ಲಕ್ಷಿಸಿದರೆ — ವಿಭಿನ್ನ ಬಳಕೆದಾರರ ಹುಡುಕಾಟದ ಫಲಿತಾಂಶಗಳು ಒಬ್ಬರಿಗೊಬ್ಬರು ಸೋರಿಕೆಯಾಗಬಹುದು.

ಇನ್ನೂ ಕೆಟ್ಟ ವಿಷಯವೆಂದರೆ, request body ಯಲ್ಲಿನ ಸೂಕ್ಷ್ಮ ಡೇಟಾ ಕ್ಯಾಶ್ ಲಾಗ್‌ಗಳು ಅಥವಾ ಡಿಬಗ್ ಔಟ್‌ಪುಟ್‌ಗಳಲ್ಲಿ ಸೇರಿದರೆ, ನೀವು ಒಂದು ಲಾಗಿಂಗ್ ಸಮಸ್ಯೆಯನ್ನು (ಪ್ರವೇಶ ಲಾಗ್‌ಗಳಲ್ಲಿ URL ನಿಯತಾಂಕಗಳು) ಮತ್ತೊಂದಕ್ಕೆ (ಕ್ಯಾಶ್ ಡಿಬಗ್ ಲಾಗ್‌ಗಳಲ್ಲಿ request bodies) ಬದಲಾಯಿಸಿಕೊಂಡಂತಾಗುತ್ತದೆ.

ಕ್ಲಾಸಿಕ್ ದೋಷಗಳು, ಹೊಸ ವೆಕ್ಟರ್‌ಗಳು

ಪ್ರತಿಯೊಂದು ಹೊಸ HTTP ವಿಧಾನವು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ದೋಷದ ವರ್ಗಗಳಿಗೆ ಹೊಸ ಅವಕಾಶಗಳನ್ನು ಪರಿಚಯಿಸುತ್ತದೆ:

• ಇನ್‌ಪುಟ್ ಸಿಂಧುತ್ವ (Input validation) ವಿಫಲತೆಗಳು. ನಿಮ್ಮ WAF POST bodies ಅನ್ನು ಪರಿಶೀಲಿಸುವ ರೀತಿಯಲ್ಲೇ QUERY request bodies ಅನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆಯೇ? ಇಲ್ಲದಿದ್ದರೆ, ದಾಳಿಕೋರರು ನಿಮ್ಮ ರಕ್ಷಣೆಯನ್ನು ಮೀರಿ ಹಾನಿಕಾರಕ ಪೇಲೋಡ್‌ಗಳನ್ನು ಕಳುಹಿಸಬಹುದು.
• ದರ ಮಿತಿ (Rate limiting) ಅಂತರಗಳು. ನಿಮ್ಮ ರೇಟ್ ಲಿಮಿಟರ್ GET ಮತ್ತು POST ವಿನಂತಿಗಳನ್ನು ಎಣಿಸುತ್ತಿದ್ದರೆ ಆದರೆ QUERY ಬಗ್ಗೆ ತಿಳಿದಿಲ್ಲದಿದ್ದರೆ, ದಾಳಿಕೋರರಿಗೆ ಉಚಿತ ವಿನಂತಿಗಳು ಸಿಗುತ್ತವೆ.
• CSRF ಮತ್ತು CORS ಗೊಂದಲ. ಬ್ರೌಸರ್‌ಗಳು ಮತ್ತು ಫ್ರೇಮ್‌ವರ್ಕ್‌ಗಳು QUERY ನ ಕ್ರಾಸ್-ಆರಿಜಿನ್ ನಿಯಮಗಳನ್ನು ಸರಿಯಾಗಿ ನಿರ್ವಹಿಸುವ ಅಗತ್ಯವಿದೆ. ಆರಂಭಿಕ ಅಳವಡಿಕೆಯ ಹಂತದಲ್ಲಿ, ತಪ್ಪು ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳು ನಡೆಯುವುದು ಬಹುತೇಕ ಖಚಿತ.
• HTTP request smuggling. QUERY ಅನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳದ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್‌ಗಳು ಮತ್ತು ರಿವರ್ಸ್ ಪ್ರಾಕ್ಸಿಗಳು ವಿನಂತಿಗಳನ್ನು ತಪ್ಪಾಗಿ ವಿಶ್ಲೇಷಿಸಬಹುದು, ಇದರಿಂದ ಫ್ರಂಟ್-ಎಂಡ್ ಮತ್ತು ಬ್ಯಾಕ್-ಎಂಡ್ ಒಂದು request ಎಲ್ಲಿ ಮುಗಿಯುತ್ತದೆ ಮತ್ತು ಮುಂದಿನದು ಎಲ್ಲಿ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ ಎಂಬುದರ ಕುರಿತು ಭಿನ್ನಾಭಿಪ್ರಾಯ ಹೊಂದಿರುವ smuggling ಅವಕಾಶಗಳನ್ನು ಸೃಷ್ಟಿಸಬಹುದು.
• ವಿಧಾನ ಗೊಂದಲ. ಒಂದು ವೇಳೆ WAF ಅಥವಾ ಮಿಡಲ್‌ವೇರ್ ಅಜ್ಞಾತ ವಿಧಾನವನ್ನು ನೋಡಿ ಡೀಫಾಲ್ಟ್ ಹ್ಯಾಂಡ್ಲರ್‌ಗೆ ಹೋದರೆ, ಅದು ಸಂಪೂರ್ಣವಾಗಿ ತಪ್ಪು ಭದ್ರತಾ ನೀತಿಯನ್ನು ಅನ್ವಯಿಸಬಹುದು.

ಇವು ಕೇವಲ ಸೈದ್ಧಾಂತಿಕ ಅಪಾಯಗಳಲ್ಲ. HTTP/2 ಪರಿಚಯಿಸಿದಾಗ, WebSockets ಬಂದಾಗ ಮತ್ತು ಪ್ರತಿಯೊಂದು ಪ್ರಮುಖ ಪ್ರೋಟೋಕಾಲ್ ಬದಲಾವಣೆಯು ಪ್ರೊಡಕ್ಷನ್ ಮೂಲಸೌಕರ್ಯವನ್ನು ತಲುಪಿದಾಗ ಕಾಣಿಸಿಕೊಂಡ ಅದೇ ಮಾದರಿಯ ಬಗ್‌ಗಳು ಇವಾಗಿವೆ. ಮಾದರಿಯು ಸುಸ್ಥಾಪಿತವಾಗಿದೆ: ಉಪಕರಣಗಳು ತಲುಪುವವರೆಗೆ ಹೊಸ ಪ್ರೋಟೋಕಾಲ್ ವೈಶಿಷ್ಟ್ಯಗಳು ತಾತ್ಕಾಲಿಕ ಭದ್ರತಾ ಅಂತರವನ್ನು ಸೃಷ್ಟಿಸುತ್ತವೆ.

ಅಳವಡಿಕೆಯು ಎಲ್ಲಿದೆ

2026 ರ ಮಧ್ಯಭಾಗದ ವೇಳೆಗೆ, ಅಳವಡಿಕೆಯು ಅದರ ಆರಂಭಿಕ ಹಂತಗಳಲ್ಲಿದೆ:

• ಬ್ರೌಸರ್‌ಗಳು ಬೆಂಬಲವನ್ನು ಸೇರಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತಿವೆ, ಆದರೆ ಇದು ಇನ್ನೂ ಸಾರ್ವತ್ರಿಕವಾಗಿಲ್ಲ.
• ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್ ಫೈರ್‌ವಾಲ್‌ಗಳು (WAFs) QUERY ವಿನಂತಿಗಳನ್ನು ಗುರುತಿಸಲು ಮತ್ತು ಸರಿಯಾಗಿ ಫಿಲ್ಟರ್ ಮಾಡಲು ತಮ್ಮ ನಿಯಮಗಳ ಗುಂಪುಗಳನ್ನು ನವೀಕರಿಸುತ್ತಿವೆ.
• CDN ಗಳು QUERY ಗಾಗಿ body-aware ಕ್ಯಾಶಿಂಗ್ ಬೆಂಬಲವನ್ನು ನೀಡುತ್ತಿವೆ, ಆದರೆ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳು ಭಿನ್ನವಾಗಿರುತ್ತವೆ.
• API ಫ್ರೇಮ್‌ವರ್ಕ್‌ಗಳು — Express, FastAPI, Spring, ASP.NET — ತಮ್ಮ ಇತ್ತೀಚಿನ ಆವೃತ್ತಿಗಳಲ್ಲಿ QUERY ಹ್ಯಾಂಡ್ಲರ್‌ಗಳನ್ನು ಸೇರಿಸುತ್ತಿವೆ.
• HTTP ಕ್ಲೈಂಟ್ ಲೈಬ್ರರಿಗಳು QUERY ವಿನಂತಿಗಳನ್ನು ಕಳುಹಿಸುವುದನ್ನು ಬೆಂಬಲಿಸಲು ನವೀಕರಿಸಲಾಗುತ್ತಿದೆ.

ಸಂಪೂರ್ಣ, ವ್ಯಾಪಕವಾದ ಅಳವಡಿಕೆಗೆ ಸಮಯ ಹಿಡಿಯುತ್ತದೆ. ಇದು ಪ್ರೋಟೋಕಾಲ್-ಮಟ್ಟದ ಬದಲಾವಣೆಯಾಗಿದೆ, ಅಂದರೆ ತಂತ್ರಜ್ಞಾನದ ಪ್ರತಿಯೊಂದು ಹಂತವೂ — ಬ್ರೌಸರ್‌ನಿಂದ CDN ಗೆ, ರಿವರ್ಸ್ ಪ್ರಾಕ್ಸಿಯಿಂದ ಅಪ್ಲಿಕೇಶನ್ ಫ್ರೇಮ್‌ವರ್ಕ್‌ಗೆ ಮತ್ತು WAF ಗೆ — ಹೊಸ ವಿಧಾನವನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕಾಗಿದೆ.

ನೀವು ಈಗ ಏನು ಮಾಡಬೇಕು

ನೀವು ಬ್ಯಾಕೆಂಡ್ ಡೆವಲಪರ್ ಅಥವಾ API ಡಿಸೈನರ್ ಆಗಿದ್ದರೆ:

1. RFC ಅನ್ನು ಓದಿ. RFC 9148 ಅಧಿಕೃತ ವಿವರಣೆಯಾಗಿದೆ. ಅನುಷ್ಠಾನಗೊಳಿಸುವ ಮೊದಲು ಅರ್ಥಶಾಸ್ತ್ರವನ್ನು (semantics) ಅರ್ಥಮಾಡಿಕೊಳ್ಳಿ.
2. ನಿಮ್ಮ ಮೂಲಸೌಕರ್ಯವನ್ನು ಆಡಿಟ್ ಮಾಡಿ. ನಿಮ್ಮ ರಿವರ್ಸ್ ಪ್ರಾಕ್ಸಿ, ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಮತ್ತು WAF QUERY ವಿನಂತಿಗಳನ್ನು ಸರಿಯಾಗಿ ದಾಟಿಸುತ್ತವೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ. ಅನೇಕ ಹಳೆಯ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳು ಅಜ್ಞಾತ HTTP ವಿಧಾನಗಳನ್ನು ಡೀಫಾಲ್ಟ್ ಆಗಿ ನಿರ್ಬಂಧಿಸುತ್ತವೆ.
3. ಪ್ರೊಡಕ್ಷನ್‌ಗೆ ಧಾವಿಸಬೇಡಿ. ಆಂತರಿಕ API ಗಳು ಅಥವಾ dev ವಾತಾವರಣದೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸಿ. ಸಾರ್ವಜನಿಕ ಇಂಟರ್ನೆಟ್‌ಗೆ QUERY ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗಳನ್ನು ಒಡ್ಡುವ ಮೊದಲು ನಿಮ್ಮ ಉಪಕರಣಗಳು ಪಕ್ವವಾಗಲು ಬಿಡಿ.
4. ನಿಮ್ಮ ಕ್ಯಾಶಿಂಗ್ ತಂತ್ರವನ್ನು ನವೀಕರಿಸಿ. ನೀವು QUERY ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಕ್ಯಾಶ್ ಮಾಡಲು ಯೋಜಿಸಿದರೆ, ನಿಮ್ಮ ಕ್ಯಾಶ್ ಕೀಗಳು ಕೇವಲ URL ಅನ್ನು ಮಾತ್ರವಲ್ಲದೆ request body ಹ್ಯಾಶ್ ಅನ್ನು ಸಹ ಒಳಗೊಂಡಿವೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ.
5. ನಿಮ್ಮ ಭದ್ರತಾ ನಿಯಂತ್ರಣಗಳನ್ನು ಪರೀಕ್ಷಿಸಿ. ರೇಟ್ ಲಿಮಿಟಿಂಗ್, ಇನ್‌ಪುಟ್ ಸಿಂಧುತ್ವ ಪರಿಶೀಲನೆ, CORS ಮತ್ತು ದೃಢೀಕರಣ ಎಲ್ಲವೂ QUERY ನೊಂದಿಗೆ ಸರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ — ಅವು ಮಾಡುತ್ತವೆ ಎಂದು ಊಹಿಸಬೇಡಿ.

ನೀವು ಭದ್ರತಾ ಸಂಶೋಧಕರಾಗಿದ್ದರೆ, ಇದು ಒಂದು ದೊಡ್ಡ ಅವಕಾಶವಾಗಿದೆ. ಪ್ರೊಡಕ್ಷನ್ ಮೂಲಸೌಕರ್ಯವನ್ನು ತಲುಪುವ ಸಂಪೂರ್ಣ ಹೊಸ HTTP ವಿಧಾನವು ಎಲ್ಲೆಡೆ ಹೊಸ ದಾಳಿ ಮೇಲ್ಮೈಯನ್ನು ಸೂಚಿಸುತ್ತದೆ. ಈಗಲೇ QUERY ಅಧ್ಯಯನ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿ, ಏಕೆಂದರೆ ಆರಂಭಿಕ ಅಳವಡಿಕೆಯ ಸಮಯದಲ್ಲಿ ಕಾಣಿಸಿಕೊಳ್ಳುವ ಬಗ್‌ಗಳು ಹೆಚ್ಚಾಗಿ ಅತ್ಯಂತ ಪ್ರಭಾವಶಾಲಿಯಾಗಿರುತ್ತವೆ.

ದೊಡ್ಡ ಚಿತ್ರಣ

QUERY ವಿಧಾನವು ಕ್ರಾಂತಿಯಲ್ಲ. ಇದು ಒಂದು ತಿದ್ದುಪಡಿ. 26 ವರ್ಷಗಳಿಂದ, ಡೆವಲಪರ್‌ಗಳು GET ಮತ್ತು POST ಅನ್ನು ಯಾವುದೇ ವಿಧಾನವನ್ನು ನಿರ್ಮಿಸದ ಕೆಲಸಕ್ಕಾಗಿ ಬಳಸುತ್ತಿದ್ದಾರೆ — ಮತ್ತು ಭದ್ರತಾ ಬಗ್‌ಗಳು, ಕ್ಯಾಶಿಂಗ್ ವೈಫಲ್ಯಗಳು ಮತ್ತು ವಾಸ್ತುಶಿಲ್ಪದ ಅಡಚಣೆಗಳಲ್ಲಿ ಬೆಲೆ ತೆರುತ್ತಿದ್ದಾರೆ.

QUERY GET ಅನ್ನು ಬದಲಾಯಿಸುವುದಿಲ್ಲ. ಇದು POST ಅನ್ನು ಬದಲಾಯಿಸುವುದಿಲ್ಲ. ಇದು ವರ್ಷಗಳ ಹಿಂದೆಯೇ ತುಂಬಬೇಕಾಗಿದ್ದ ಕೊರತೆಯನ್ನು ತುಂಬುತ್ತದೆ: request body ಅನ್ನು ಬೆಂಬಲಿಸುವ ಸುರಕ್ಷಿತ, ಓದಲು ಮಾತ್ರ ಇರುವ HTTP ವಿಧಾನ.

ಪ್ರೋಟೋಕಾಲ್ ಅಧಿಕೃತವಾಗಿದೆ. RFC ಪ್ರಕಟಿಸಲಾಗಿದೆ. ಪರಿಸರ ವ್ಯವಸ್ಥೆಯು ಹೊಂದಿಕೊಳ್ಳುತ್ತಿದೆ. ನೀವು API ಗಳನ್ನು ನಿರ್ಮಿಸುತ್ತಿರಲಿ, ಮೂಲಸೌಕರ್ಯವನ್ನು ಬಲಪಡಿಸುತ್ತಿರಲಿ ಅಥವಾ ದೋಷಗಳನ್ನು ಹುಡುಕುತ್ತಿರಲಿ — QUERY ವಿಧಾನವು ನೀವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕಾದ ವಿಷಯವಾಗಿದೆ.

ವೆಬ್‌ಗೆ ಹೊಸ ಕ್ರಿಯಾಪದ ಸಿಕ್ಕಿದೆ. ಅದನ್ನು ಬುದ್ಧಿವಂತಿಕೆಯಿಂದ ಬಳಸಿ.

ಪ್ರಯೋಜನಗಳು

• URL ಉದ್ದದ ಮಿತಿಗಳನ್ನು ಪರಿಹರಿಸುತ್ತದೆ: ಸಂಕೀರ್ಣ ಹುಡುಕಾಟದ ಪೇಲೋಡ್‌ಗಳು URL ನಿಂದ request body ಗೆ ಚಲಿಸುತ್ತವೆ — ಇನ್ನು ಮುಂದೆ ಕಡಿತಗೊಳಿಸುವಿಕೆ ಇಲ್ಲ
• ಭದ್ರತೆಯ ಸುಧಾರಣೆ: ಸೂಕ್ಷ್ಮ ಹುಡುಕಾಟ ನಿಯತಾಂಕಗಳು ಇನ್ನು ಮುಂದೆ ಬ್ರೌಸರ್ ಇತಿಹಾಸ, ಪ್ರವೇಶ ಲಾಗ್‌ಗಳು ಮತ್ತು ಪ್ರಾಕ್ಸಿ ಕ್ಯಾಶ್‌ಗಳಲ್ಲಿ ಸೋರಿಕೆಯಾಗುವುದಿಲ್ಲ
• ಸರಿಯಾದ ಅರ್ಥಶಾಸ್ತ್ರ (semantics): ಸರ್ವರ್‌ಗಳು, ಮಿಡಲ್‌ವೇರ್‌ಗಳು ಮತ್ತು WAF ಗಳು ಊಹಿಸದೆ ಓದುವಿಕೆಗಳನ್ನು ಬರೆಯುವಿಕೆಯಿಂದ ಪ್ರತ್ಯೇಕಿಸಬಹುದು
• ಸ್ವಾಭಾವಿಕ ಕ್ಯಾಶ್ ಮಾಡುವಿಕೆ: HTTP ಮೂಲಸೌಕರ್ಯವು QUERY ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಕ್ಯಾಶ್ ಮಾಡಬಹುದು — POST ಪರಿಹಾರಗಳಂತಲ್ಲದೆ
• Idempotent ಮತ್ತು ಸುರಕ್ಷಿತ: ಮತ್ತೆ ಪ್ರಯತ್ನಿಸುವುದು ಹಾನಿಕರವಲ್ಲ, ಇದು ವಿತರಿಸಲಾದ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ ದೋಷ ನಿರ್ವಹಣೆಯನ್ನು ಸರಳಗೊಳಿಸುತ್ತದೆ
• ಪ್ರೋಟೋಕಾಲ್-ಮಟ್ಟದ ಪರಿಹಾರ: GraphQL ನಂತಹ ಅಪ್ಲಿಕೇಶನ್-ಮಟ್ಟದ ಪರಿಹಾರಗಳ ಅಗತ್ಯವಿಲ್ಲದೇ ಎಲ್ಲಾ REST API ಗಳಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ

ದೋಷಗಳು

• ಹೊಸ ದಾಳಿ ಮೇಲ್ಮೈ: Smuggling, ವಿಧಾನ ಗೊಂದಲ, CSRF ಮತ್ತು CORS ಸಮಸ್ಯೆಗಳಿಗೆ ಹೊಸ ವೆಕ್ಟರ್‌ಗಳನ್ನು ಪರಿಚಯಿಸುತ್ತದೆ
• ಕ್ಯಾಶಿಂಗ್‌ ಸಂಕೀರ್ಣತೆ: ಕ್ಯಾಶ್ ಅನುಷ್ಠಾನಗಳು ಕೀಗಳಲ್ಲಿ request body ಅನ್ನು ಸೇರಿಸಬೇಕು — ತಪ್ಪು ಕಾನ್ಫಿಗರೇಶನ್ ಡೇಟಾವನ್ನು ಸೋರಿಕೆ ಮಾಡುತ್ತದೆ
• ನಿಧಾನಗತಿಯ ಅಳವಡಿಕೆ: ಇದು ಎಂಡ್-ಟು-ಎಂಡ್ ವಿಶ್ವಾಸಾರ್ಹವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಮೊದಲು ಬ್ರೌಸರ್‌ಗಳು, CDN ಗಳು, WAF ಗಳು ಮತ್ತು ಫ್ರೇಮ್‌ವರ್ಕ್‌ಗಳಿಗೆ ನವೀಕರಣಗಳ ಅಗತ್ಯವಿದೆ
• ಉಪಕರಣಗಳ ಅಂತರಗಳು: ಡಿಬಗ್ ಮಾಡುವ ಉಪಕರಣಗಳು, ಮಾನಿಟರಿಂಗ್ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ಗಳು ಮತ್ತು ಲಾಗ್ ಪಾರ್ಸರ್‌ಗಳು ಇನ್ನೂ QUERY ಅನ್ನು ನಿರ್ವಹಿಸದೇ ಇರಬಹುದು
• ಮೂಲಸೌಕರ್ಯ ತಡೆಗೋಡೆಗಳು: ಹಳೆಯ ರಿವರ್ಸ್ ಪ್ರಾಕ್ಸಿಗಳು ಮತ್ತು ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್‌ಗಳು QUERY ವಿನಂತಿಗಳನ್ನು ಯಾವುದೇ ಸೂಚನೆ ಇಲ್ಲದೆ ಕೈಬಿಡಬಹುದು ಅಥವಾ ತಿರಸ್ಕರಿಸಬಹುದು.
• ಸುಳ್ಳು ಭದ್ರತಾ ಭಾವನೆ: URL ಗಳಿಂದ ಪ್ಯಾರಾಮೀಟರ್‌ಗಳನ್ನು ಹೊರಗೆ ಸರಿಸುವುದು ಲಾಗಿಂಗ್ ಅಪಾಯಗಳನ್ನು ಇಲ್ಲದಂತೆ ಮಾಡುವುದಿಲ್ಲ — ಬಾಡಿಗಳನ್ನು ಇಂದಿಗೂ ಲಾಗ್ ಮಾಡಬಹುದು

ಎಚ್ಚರಿಕೆ

ಈ ಲೇಖನವು ಜೂನ್ 2026 ರಲ್ಲಿ ಪ್ರಮಾಣೀಕರಿಸಲಾದ RFC 9148 ನಲ್ಲಿ ವ್ಯಾಖ್ಯಾನಿಸಲಾದ QUERY HTTP ವಿಧಾನದ ಕುರಿತು ಚರ್ಚಿಸುತ್ತದೆ. ಬ್ರೌಸರ್ ಬೆಂಬಲ, ಫ್ರೇಮ್‌ವರ್ಕ್ ಬೆಂಬಲ ಮತ್ತು ಮೂಲಸೌಕರ್ಯ ಹೊಂದಾಣಿಕೆ ವೇಗವಾಗಿ ವಿಕಸನಗೊಳ್ಳುತ್ತಿವೆ. ನಿಮ್ಮ ಸ್ಟ್ಯಾಕ್‌ನ ಪ್ರತಿಯೊಂದು ಹಂತವೂ — CDN ನಿಂದ WAF ವರೆಗೆ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಫ್ರೇಮ್‌ವರ್ಕ್‌ವರೆಗೆ — ಹೊಸ ವಿಧಾನವನ್ನು ಸರಿಯಾಗಿ ನಿರ್ವಹಿಸುತ್ತದೆ ಎಂದು ಪರಿಶೀಲಿಸದೆ ಪ್ರೊಡಕ್ಷನ್‌ನಲ್ಲಿ QUERY ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗಳನ್ನು ಡೆಪ್ಲಾಯ್ ಮಾಡಬೇಡಿ. ಇಲ್ಲಿ ವಿವರಿಸಲಾದ ಭದ್ರತಾ ಗುಣಲಕ್ಷಣಗಳು ಸರಿಯಾದ ಅನುಷ್ಠಾನವನ್ನು ಆಧರಿಸಿವೆ; ತಪ್ಪಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾದ ಮೂಲಸೌಕರ್ಯವು QUERY ತಡೆಯಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾದ ಭದ್ರತಾ ಲೋಪಗಳನ್ನೇ ಸೃಷ್ಟಿಸಬಹುದು. ಯಾವಾಗಲೂ ಮೊದಲು ನಿಯಂತ್ರಿತ ವಾತಾವರಣದಲ್ಲಿ ಪರೀಕ್ಷಿಸಿ.

ಪದೇ ಪದೇ ಕೇಳಲಾಗುವ ಪ್ರಶ್ನೆಗಳು

• HTTP QUERY ವಿಧಾನ ಎಂದರೇನು ಮತ್ತು ಇದು GET ಗಿಂತ ಹೇಗೆ ಭಿನ್ನವಾಗಿದೆ?
• ನಾನು ಈಗಲೇ ಪ್ರೊಡಕ್ಷನ್ API ಗಳಲ್ಲಿ QUERY ಅನ್ನು ಬಳಸಬಹುದೇ?
• POST ಮೂಲಕ ಸರ್ಚ್ ಪೇಲೋಡ್‌ಗಳನ್ನು ಕಳುಹಿಸುವುದಕ್ಕೆ ಹೋಲಿಸಿದರೆ QUERY ಹೇಗಿದೆ?
• CDN ಗಳು ಮತ್ತು ಪ್ರಾಕ್ಸಿಗಳು QUERY ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಸರಿಯಾಗಿ ಕ್ಯಾಶ್ ಮಾಡುತ್ತವೆಯೇ?
• QUERY ವಿಧಾನವು ಯಾವ ಭದ್ರತಾ ಅಪಾಯಗಳನ್ನು ತರುತ್ತದೆ?
• ಸಂಕೀರ್ಣ ಡೇಟಾ ಪಡೆಯಲು QUERY ಯು GraphQL ಅನ್ನು ಬದಲಾಯಿಸುತ್ತದೆಯೇ?
• ನನ್ನ Express ಅಥವಾ FastAPI ಅಪ್ಲಿಕೇಶನ್‌ಗೆ QUERY ಬೆಂಬಲವನ್ನು ಸೇರಿಸುವುದು ಹೇಗೆ?
• ನನ್ನ WAF ಯು QUERY ವಿಧಾನವನ್ನು ಗುರುತಿಸದಿದ್ದರೆ ಏನಾಗುತ್ತದೆ?

ಟ್ಯಾಗ್‌ಗಳು

#http #query-method #rfc-9148 #api-design #web-security #rest-api #caching #http-methods