For sixteen years, developers who needed to ask complex questions of a server have been stuck with a workaround. When a

ಹದಿನಾರು ವರ್ಷಗಳಿಂದ, ಸರ್ವರ್‌ನಿಂದ ಸಂಕೀರ್ಣ ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳಬೇಕಾದ ಡೆವಲಪರ್‌ಗಳು ಒಂದು ಪರ್ಯಾಯ ಮಾರ್ಗಕ್ಕೆ (workaround) ಸೀಮಿತರಾಗಿದ್ದರು. ಒಂದು ವೇಳೆ ಸರ್ಚ್ ಪೇಲೋಡ್ (search payload) URL ಗೆ ಹೊಂದದಷ್ಟು ದೊಡ್ಡದಾಗಿದ್ದಾಗ, ಅಥವಾ ನೆಸ್ಟೆಡ್ ಫಿಲ್ಟರ್‌ಗಳು (nested filters) ಮತ್ತು ಸಂವೇದನಾಶೀಲ ಪ್ಯಾರಾಮೀಟರ್‌ಗಳು ಕ್ವೇರಿ ಸ್ಟ್ರಿಂಗ್‌ನಲ್ಲಿ (query string) ಹೊಂದಾಣಿಕೆಯಾಗದಿದ್ದಾಗ, ಏಕೈಕ ಪ್ರಾಯೋಗಿಕ ಆಯ್ಕೆ POST ಆಗಿತ್ತು. ಇದು ಬೈಟ್‌ಗಳನ್ನು (bytes) ಸಾಗಿಸುತ್ತಿತ್ತು, ಆದರೆ ಅದರ ಉದ್ದೇಶದ ಬಗ್ಗೆ ಸುಳ್ಳು ಹೇಳುತ್ತಿತ್ತು. POST ಎಂಬುದು ಸ್ಥಿತಿಯ ಬದಲಾವಣೆಯನ್ನು (change of state) ಸೂಚಿಸುತ್ತದೆ. ಇದನ್ನು ಕೇವಲ ಓದಲು ಮಾತ್ರ ಬಳಸುವ (read-only) ಕಾರ್ಯಾಚರಣೆಗೆ ಬಳಸಿದಾಗ, ಇಡೀ ನೆಟ್‌ವರ್ಕ್ ಪಾತ್—ಕ್ಯಾಶೆಗಳು (caches), ಪ್ರೊಕ್ಸಿಗಳು (proxies) ಮತ್ತು ಬ್ರೌಸರ್‌ಗಳು—ಒಂದು ಸಾಮಾನ್ಯ ಹುಡುಕಾಟವನ್ನು ಡೇಟಾಬೇಸ್ ಅನ್ನು ಬದಲಾಯಿಸಬಹುದು ಎಂದು ಭಾವಿಸುವಂತೆ ಮಾಡುತ್ತದೆ.

ಆ ರಾಜಿ ಕೊನೆಗೂ ಅಂತ್ಯಗೊಂಡಿದೆ. ಜೂನ್ 2026 ರಲ್ಲಿ, IETF RFC 10008 ಅನ್ನು ಪ್ರಕಟಿಸಿ, QUERY ವಿಧಾನವನ್ನು ಅಧಿಕೃತವಾಗಿ ಪ್ರಮಾಣೀಕರಿಸಿತು. 2010 ರಲ್ಲಿ PATCH ಅನ್ನು ಪರಿಚಯಿಸಿದ ನಂತರ ಬಂದ ಮೊದಲ ಹೊಸ HTTP ವಿಧಾನ ಇದಾಗಿದೆ. QUERY ವಿಧಾನವು ವಿಶೇಷವಾಗಿ ಬಾಡಿ (body) ಅಗತ್ಯವಿರುವ ಸುರಕ್ಷಿತ ಮತ್ತು ಐಡೆಂಪೊಟೆಂಟ್ (idempotent) ವಿನಂತಿಗಳಿಗಾಗಿ ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ. ಇದು ಸರ್ವರ್ ಸ್ಥಿತಿಯನ್ನು ಬದಲಾಯಿಸುವುದಿಲ್ಲ. ಒಂದೇ ವಿನಂತಿಯನ್ನು ಪುನರಾವರ್ತಿಸುವುದು ಒಂದೇ ಫಲಿತಾಂಶವನ್ನು ನೀಡುತ್ತದೆ. ಇದು ಕ್ಯಾಶೆ ಮಾಡಬಹುದಾದ (cacheable) ವಿಧಾನವಾಗಿದೆ, ಅಂದರೆ ಮಧ್ಯಂತರ ವ್ಯವಸ್ಥೆಗಳು (intermediaries) ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಸಂಗ್ರಹಿಸಿ ಮರುಬಳಕೆ ಮಾಡಬಹುದು. ಮತ್ತು GET ನಂತಲ್ಲದೆ, ಇದು POST ನಂತೆಯೇ ಡೇಟಾ ಪೇಲೋಡ್ ಅನ್ನು ಅನುಮತಿಸುತ್ತದೆ.

GraphQL ಕ್ವೇರಿಗಳು ಮತ್ತು ಸಂಕೀರ್ಣ REST ಸರ್ಚ್ ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗಳು (endpoints) ಇದರ ದೊಡ್ಡ ಲಾಭ ಪಡೆಯುತ್ತವೆ. ನೀವು ಇನ್ನು ಮುಂದೆ ಅರವತ್ತು ಕ್ವೇರಿ ಪ್ಯಾರಾಮೀಟರ್‌ಗಳನ್ನು ಒಂದು URL ಗೆ ಅಡಗಿಸಬೇಕಾಗಿಲ್ಲ ಅಥವಾ ಮಧ್ಯಂತರ ವ್ಯವಸ್ಥೆಗಳು ಕ್ಯಾಶ್ ಮಾಡಲು ನಿರಾಕರಿಸುವಂತಹ JSON ಫಿಲ್ಟರ್ ಡಾಕ್ಯುಮೆಂಟ್ ಅನ್ನು POST ಬಾಡಿಯೊಳಗೆ ಅಡಗಿಸಬೇಕಾಗಿಲ್ಲ. ಈಗ ಇದರ ಅರ್ಥದ ದೃಷ್ಟಿಕೋನವು (semantics) ಪ್ರಾಮಾಣಿಕವಾಗಿದೆ.

ಆದರೆ RFC ಎಂಬುದು ಕೇವಲ ಕಾಗದದ ಮೇಲಿನ ಅಕ್ಷರಗಳಷ್ಟೇ. ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಮತ್ತು ಬಳಕೆದಾರರ ನಡುವೆ ದಪ್ಪವಾದ ಮೂಲಸೌಕರ್ಯದ ಪದರವಿದೆ (infrastructure layer), ಮತ್ತು ಅದರಲ್ಲಿ ಹೆಚ್ಚಿನವು QUERY ಬಗ್ಗೆ ಎಂದಿಗೂ ಕೇಳಿಲ್ಲ.

ಕ್ಯಾಶಿಂಗ್ ಸಮಸ್ಯೆ ಇನ್ನೂ ಪರಿಹಾರವಾಗಿಲ್ಲ

GET ವಿನಂತಿಯೊಂದಿಗೆ, ಕ್ಯಾಶಿಂಗ್ ಸರಳವಾಗಿರುತ್ತದೆ. ಕ್ಯಾಶ್ ಕೀ (cache key) ಎಂದರೆ URI. ಹೆಡರ್ಸ್‌ಗಳು ಅನುಮತಿಸಿದರೆ, ಒಂದೇ URL ಅನ್ನು ಬಳಸುವ ಇಬ್ಬರು ಬಳಕೆದಾರರು ಒಂದೇ ಸಂಗ್ರಹಿಸಿದ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಪಡೆಯುತ್ತಾರೆ.

QUERY ಆ ಮಾದರಿಯನ್ನು ಮುರಿಯುತ್ತದೆ ಏಕೆಂದರೆ ವಿನಂತಿ ಪ್ಯಾರಾಮೀಟರ್‌ಗಳು ಬಾಡಿಯಲ್ಲಿ (body) ಇರುತ್ತವೆ. ಎರಡು ವಿನಂತಿಗಳು ಒಂದೇ ಆಗಿವೆ ಎಂದು ಕ್ಯಾಶ್ ಗುರುತಿಸಲು, ಕ್ಯಾಶ್ ಕೀಯು URI ಮತ್ತು ಬಾಡಿ ಕಂಟೆಂಟ್ ಎರಡನ್ನೂ ಒಳಗೊಂಡಿರಬೇಕು. ಈ ಅಗತ್ಯತೆಯು ನಿಜವಾದ ಕಾರ್ಯಾಚರಣೆಯ ಅಡಚಣೆಯನ್ನು (operational friction) ಉಂಟುಮಾಡುತ್ತದೆ.

ಮೊದಲನೆಯದಾಗಿ, ಎಡ್ಜ್ ಸರ್ವರ್‌ಗಳು ಮತ್ತು CDNs ಹ್ಯಾಶ್ (hash) ಅನ್ನು ಲೆಕ್ಕಹಾಕುವ ಮೊದಲು ಇಡೀ ವಿನಂತಿ ಬಾಡಿಯನ್ನು ಬಫರ್ (buffer) ಮಾಡಬೇಕು. ಇದು ಎಡ್ಜ್ ನೋಡ್‌ನಲ್ಲಿ ಮೆಮೊರಿ ಮತ್ತು ಸಮಯವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಎರಡನೆಯದಾಗಿ, ತಾರ್ಕಿಕವಾಗಿ ಒಂದೇ ರೀತಿಯ ಕ್ವೇರಿಗಳು ಒಂದೇ ರೀತಿಯ ಬೈಟ್‌ಗಳನ್ನು ನೀಡದಿರಬಹುದು. ಒಂದು ಕ್ಲೈಂಟ್ {"status":"active"} ಅನ್ನು ಕಳುಹಿಸಬಹುದು, ಆದರೆ ಇನ್ನೊಂದು ಕ್ಲೈಂಟ್ ವಿಭಿನ್ನ ವೈಟ್‌ಸ್ಪೇಸ್ (whitespace) ಅಥವಾ ಕೀ ಆರ್ಡರಿಂಗ್‌ನೊಂದಿಗೆ (key ordering) {"status": "active"} ಅನ್ನು ಕಳುಹಿಸಬಹುದು. ಕ್ಯಾಶಿಂಗ್ ಪದರವು ಬಾಡಿಯನ್ನು ಪಾರ್ಸ್ (parse), ನಾರ್ಮಲೈಸ್ (normalize) ಮತ್ತು ಕೆನಾನಿಕಲೈಸ್ (canonicalize) ಮಾಡದ ಹೊರತು—ಅಂದರೆ JSON ಕೀಗಳನ್ನು ವಿಂಗಡಿಸುವುದು, ಅಪ್ರಸ್ತುತ ಫಾರ್ಮ್ಯಾಟಿಂಗ್ ಅನ್ನು ತೆಗೆದುಹಾಕುವುದು ಮತ್ತು ಎನ್ಕೋಡಿಂಗ್ ವ್ಯತ್ಯಾಸಗಳನ್ನು ನಿರ್ವಹಿಸುವುದು—ಅದೇ ಪ್ರಶ್ನೆಯು ಪ್ರತಿ ಬಾರಿಯೂ ಕ್ಯಾಶ್ ಅನ್ನು ತಪ್ಪಿಸಿಕೊಳ್ಳುತ್ತದೆ.

ಅತ್ಯಂತ ನಿರ್ಣಾಯಕವಾಗಿ, ಪ್ರಮುಖ CDNs ಇನ್ನೂ QUERY ಗಾಗಿ ವಿನಂತಿ ಬಾಡಿಯ ಆಧಾರದ ಮೇಲೆ ಕ್ಯಾಶ್ ಅನ್ನು ವಿಂಗಡಿಸುವುದಿಲ್ಲ. ಉದಾಹರಣೆಗೆ, Cloudflare ತನ್ನ ಪ್ರಸ್ತುತ ರೂಪದಲ್ಲಿ ಈ ವಿಧಾನಕ್ಕಾಗಿ ಬಾಡಿಯನ್ನು ಕ್ಯಾಶ್ ಕೀಯಿನ ಭಾಗವಾಗಿ ಪರಿಗಣಿಸುವುದಿಲ್ಲ. 'ಕ್ಯಾಶೆಬಲ್' ಎಂದರೆ 'ಕ್ಯಾಶ್ ಆಗಿದೆ' ಎಂದು ಭಾವಿಸಿ ನೀವು QUERY ಅನ್ನು ಬಳಸಿದರೆ, ನೀವು ಕೊಲಿಷನ್ ಎರ್ರರ್‌ಗಳನ್ನು (collision errors), ಸಾರ್ವತ್ರಿಕ ಕ್ಯಾಶ್ ಮಿಸ್‌ಗಳನ್ನು (universal cache misses) ಅಥವಾ ಸಂಬಂಧವಿಲ್ಲದ ವಿನಂತಿಗಳ ನಡುವೆ ಪ್ರತಿಕ್ರಿಯೆಗಳು ಸೋರಿಕೆಯಾಗುವುದನ್ನು ನೋಡಬಹುದು. ನಿಮ್ಮ ಪ್ರೊವೈಡರ್ ಸ್ಪಷ್ಟ ಬೆಂಬಲವನ್ನು ಪ್ರಕಟಿಸುವವರೆಗೆ, ಪ್ರೊಡಕ್ಷನ್‌ನಲ್ಲಿ QUERY ಗಮನಾರ್ಹವಾಗಿ ಕ್ಯಾಶೆ ಮಾಡಬಹುದಾದ ವಿಧಾನವಲ್ಲ ಎಂದು ಭಾವಿಸಿ.

ನಿಮ್ಮ ಪರಿಕರಗಳು ಬಹುಶಃ ಮೊದಲು ಇದನ್ನು ತಡೆಯಬಹುದು

ಪ್ರತಿಯೊಂದು HTTP ವಿನಂತಿಯು ಮಧ್ಯಂತರ ಬಾಕ್ಸ್‌ಗಳ (middleboxes) ಮೂಲಕ ಹಾದುಹೋಗುತ್ತದೆ ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಹೆಚ್ಚಿನವು ಯಾವ ವಿಧಾನಗಳು ಕಾನೂನುಬದ್ಧವಾಗಿವೆ ಎಂಬುದರ ಬಗ್ಗೆ ಕಟ್ಟುನಿಟ್ಟಾದ ನಿಯಮಗಳನ್ನು ಜಾರಿಗೆ ತರುತ್ತವೆ.

ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್ ಫೈರ್‌ವಾಲ್‌ಗಳು (WAF) ಮತ್ತು API ಗೇಟ್‌ವೇಗಳು ಹೆಚ್ಚಾಗಿ ನಿರ್ದಿಷ್ಟ ಅಲೋಲಿಸ್ಟ್‌ಗಳನ್ನು (allowlists) ಅವಲಂಬಿಸಿರುತ್ತವೆ. ಸಾಮಾನ್ಯ ನಿಯಮಾವಳಿಗಳು GET, POST, PUT, DELETE ಮತ್ತು PATCH ಅನ್ನು ಅನುಮತಿಸುತ್ತವೆ. ಇವುಗಳಲ್ಲದ ಯಾವುದನ್ನೇ ಆದರೂ ಡ್ರಾಪ್ ಮಾಡಲಾಗುತ್ತದೆ ಅಥವಾ 405 Method Not Allowed ಎಂಬ ಉತ್ತರವನ್ನು ನೀಡಲಾಗುತ್ತದೆ. ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಕೋಡ್ ತಲುಪುವ ಮೊದಲೇ QUERY ಅಂತಹ ಗೋಡೆಗಳಿಗೆ ಅಡಕವಾಗುತ್ತದೆ.

ಸೆಕ್ಯೂರಿಟಿ ರೂಲ್ ಇಂಜಿನ್‌ಗಳು ಮತ್ತೊಂದು ಅಡೆತಡೆಯನ್ನು ಉಂಟುಮಾಡುತ್ತವೆ. ಕೆಲವು ಇಂಟ್ರೂಷನ್ ಡಿಟೆಕ್ಷನ್ ಸಿಸ್ಟಮ್‌ಗಳು ಬಾಡಿಯನ್ನು ಹೊಂದಿರುವ ವಿನಂತಿಯನ್ನು