JSON-RPC? ಟ್ರಿಕಿ ರೆಸ್ಟ್ ತೆಗೆದುಕೊಳ್ಳಿ

ಹೆಡ್‌ಲೈನ್ ಆರೋಗ್ಯಕರ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಉಂಟುಮಾಡಿದೆ ಎಂದು ನನಗೆ ಖಾತ್ರಿಯಿದೆ - “ಸರಿ, ಅದು ಮತ್ತೆ ಪ್ರಾರಂಭವಾಗಿದೆ...” ಆದರೆ ನಾನು 5-10 ನಿಮಿಷಗಳ ಕಾಲ ನಿಮ್ಮ ಗಮನವನ್ನು ಸೆಳೆಯುತ್ತೇನೆ ಮತ್ತು ನಿಮ್ಮ ನಿರೀಕ್ಷೆಗಳನ್ನು ನಿರಾಶೆಗೊಳಿಸದಿರಲು ನಾನು ಪ್ರಯತ್ನಿಸುತ್ತೇನೆ.

ಲೇಖನದ ರಚನೆಯು ಈ ಕೆಳಗಿನಂತಿರುತ್ತದೆ: ಸ್ಟೀರಿಯೊಟೈಪಿಕಲ್ ಹೇಳಿಕೆಯನ್ನು ತೆಗೆದುಕೊಳ್ಳಲಾಗುತ್ತದೆ ಮತ್ತು ಈ ಸ್ಟೀರಿಯೊಟೈಪ್ನ ಹೊರಹೊಮ್ಮುವಿಕೆಯ "ಸ್ವಭಾವ" ಬಹಿರಂಗಗೊಳ್ಳುತ್ತದೆ. ನಿಮ್ಮ ಯೋಜನೆಗಳಲ್ಲಿ ಡೇಟಾ ವಿನಿಮಯ ಮಾದರಿಯ ಆಯ್ಕೆಯನ್ನು ಹೊಸ ಕೋನದಿಂದ ನೋಡಲು ಇದು ನಿಮ್ಮನ್ನು ಅನುಮತಿಸುತ್ತದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ.

RPC ಎಂದರೇನು ಎಂಬುದರ ಕುರಿತು ಸ್ಪಷ್ಟವಾಗಲು, ನಾನು ಮಾನದಂಡವನ್ನು ಪರಿಗಣಿಸಲು ಪ್ರಸ್ತಾಪಿಸುತ್ತೇನೆ JSON-RPC 2.0. REST ಯೊಂದಿಗೆ ಯಾವುದೇ ಸ್ಪಷ್ಟತೆ ಇಲ್ಲ. ಮತ್ತು ಅದು ಇರಬಾರದು. ನೀವು REST ಬಗ್ಗೆ ತಿಳಿದುಕೊಳ್ಳಬೇಕಾದ ಎಲ್ಲವೂ - ಇದು ಅಸ್ಪಷ್ಟವಾಗಿದೆ HTTP.

RPC ವಿನಂತಿಗಳು ವೇಗವಾಗಿ ಮತ್ತು ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾಗಿರುತ್ತವೆ ಏಕೆಂದರೆ ಅವುಗಳು ಬ್ಯಾಚ್ ವಿನಂತಿಗಳನ್ನು ಮಾಡಲು ನಿಮಗೆ ಅವಕಾಶ ಮಾಡಿಕೊಡುತ್ತವೆ.

ಪಾಯಿಂಟ್ ಆರ್ಪಿಸಿಯಲ್ಲಿ ನೀವು ಒಂದು ವಿನಂತಿಯಲ್ಲಿ ಹಲವಾರು ಕಾರ್ಯವಿಧಾನಗಳನ್ನು ಏಕಕಾಲದಲ್ಲಿ ಕರೆಯಬಹುದು. ಉದಾಹರಣೆಗೆ, ಬಳಕೆದಾರರನ್ನು ರಚಿಸಿ, ಅವರಿಗೆ ಅವತಾರವನ್ನು ಸೇರಿಸಿ ಮತ್ತು ಅದೇ ವಿನಂತಿಯಲ್ಲಿ, ಕೆಲವು ವಿಷಯಗಳಿಗೆ ಅವರನ್ನು ಚಂದಾದಾರರಾಗಿ. ಕೇವಲ ಒಂದು ವಿನಂತಿ, ಮತ್ತು ಎಷ್ಟು ಪ್ರಯೋಜನ!

ವಾಸ್ತವವಾಗಿ, ನೀವು ಕೇವಲ ಒಂದು ಬ್ಯಾಕೆಂಡ್ ನೋಡ್ ಹೊಂದಿದ್ದರೆ, ಬ್ಯಾಚ್ ವಿನಂತಿಯೊಂದಿಗೆ ಅದು ವೇಗವಾಗಿ ಕಾಣುತ್ತದೆ. ಏಕೆಂದರೆ ಮೂರು REST ವಿನಂತಿಗಳಿಗೆ ಸಂಪರ್ಕಗಳನ್ನು ಸ್ಥಾಪಿಸಲು ಒಂದು ನೋಡ್‌ನಿಂದ ಮೂರು ಪಟ್ಟು ಹೆಚ್ಚು ಸಂಪನ್ಮೂಲಗಳು ಬೇಕಾಗುತ್ತವೆ.

REST ಸಂದರ್ಭದಲ್ಲಿ ಮೊದಲ ವಿನಂತಿಯು ನಂತರದ ವಿನಂತಿಗಳನ್ನು ಮಾಡಲು ಬಳಕೆದಾರ ID ಅನ್ನು ಹಿಂತಿರುಗಿಸಬೇಕು ಎಂಬುದನ್ನು ಗಮನಿಸಿ. ಇದು ಒಟ್ಟಾರೆ ಫಲಿತಾಂಶದ ಮೇಲೆ ನಕಾರಾತ್ಮಕ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ.

ಆದರೆ ಅಂತಹ ಮೂಲಸೌಕರ್ಯಗಳನ್ನು ಆಂತರಿಕ ಪರಿಹಾರಗಳು ಮತ್ತು ಎಂಟರ್‌ಪ್ರೈಸ್‌ನಲ್ಲಿ ಮಾತ್ರ ಕಾಣಬಹುದು. ಕೊನೆಯ ಉಪಾಯವಾಗಿ, ಸಣ್ಣ ವೆಬ್ ಯೋಜನೆಗಳಲ್ಲಿ. ಆದರೆ ಪೂರ್ಣ ಪ್ರಮಾಣದ WEB ಪರಿಹಾರಗಳು ಮತ್ತು ಹೈಲೋಡ್ ಎಂದು ಕರೆಯಲ್ಪಡುವವುಗಳು ನಿರ್ಮಿಸಲು ಯೋಗ್ಯವಾಗಿಲ್ಲ. ಅವರ ಮೂಲಸೌಕರ್ಯವು ಹೆಚ್ಚಿನ ಲಭ್ಯತೆ ಮತ್ತು ಹೊರೆಯ ಮಾನದಂಡಗಳನ್ನು ಪೂರೈಸಬೇಕು. ಮತ್ತು ಚಿತ್ರ ಬದಲಾಗುತ್ತಿದೆ.

ಅದೇ ಸನ್ನಿವೇಶದಲ್ಲಿ ಮೂಲಸೌಕರ್ಯ ಚಟುವಟಿಕೆಯ ಚಾನಲ್‌ಗಳನ್ನು ಹಸಿರು ಬಣ್ಣದಲ್ಲಿ ಗುರುತಿಸಲಾಗಿದೆ. RPC ಈಗ ಹೇಗೆ ವರ್ತಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಗಮನಿಸಿ. ವಿನಂತಿಯು ಬ್ಯಾಲೆನ್ಸರ್‌ನಿಂದ ಬ್ಯಾಕೆಂಡ್‌ಗೆ ಕೇವಲ ಒಂದು ಕಾಲಿನ ಮೇಲೆ ಮೂಲಸೌಕರ್ಯವನ್ನು ಬಳಸುತ್ತದೆ. ಮೊದಲ ವಿನಂತಿಯಲ್ಲಿ REST ಇನ್ನೂ ಕಳೆದುಹೋದರೂ, ಸಂಪೂರ್ಣ ಮೂಲಸೌಕರ್ಯವನ್ನು ಬಳಸಿಕೊಂಡು ಕಳೆದುಹೋದ ಸಮಯವನ್ನು ಅದು ಸರಿದೂಗಿಸುತ್ತದೆ.

ಸ್ಕ್ರಿಪ್ಟ್‌ಗೆ ಪುಷ್ಟೀಕರಣಕ್ಕಾಗಿ ಎರಡು ವಿನಂತಿಗಳನ್ನು ನಮೂದಿಸಲು ಸಾಕು, ಆದರೆ, ಐದು ಅಥವಾ ಹತ್ತು ಎಂದು ಹೇಳಿ ... ಮತ್ತು “ಈಗ ಯಾರು ಗೆಲ್ಲುತ್ತಾರೆ?” ಎಂಬ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರ. ಅಸ್ಪಷ್ಟವಾಗುತ್ತದೆ.

ಸಮಸ್ಯೆಯ ಬಗ್ಗೆ ಇನ್ನೂ ವಿಶಾಲವಾದ ನೋಟವನ್ನು ತೆಗೆದುಕೊಳ್ಳಲು ನಾನು ಪ್ರಸ್ತಾಪಿಸುತ್ತೇನೆ. ಮೂಲಸೌಕರ್ಯ ಚಾನಲ್‌ಗಳನ್ನು ಹೇಗೆ ಬಳಸಲಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ರೇಖಾಚಿತ್ರವು ತೋರಿಸುತ್ತದೆ, ಆದರೆ ಮೂಲಸೌಕರ್ಯವು ಚಾನಲ್‌ಗಳಿಗೆ ಸೀಮಿತವಾಗಿಲ್ಲ. ಹೆಚ್ಚಿನ ಲೋಡ್ ಮೂಲಸೌಕರ್ಯದ ಪ್ರಮುಖ ಅಂಶವೆಂದರೆ ಸಂಗ್ರಹಗಳು. ಈಗ ಕೆಲವು ರೀತಿಯ ಬಳಕೆದಾರ ಕಲಾಕೃತಿಯನ್ನು ಪಡೆಯೋಣ. ಪದೇ ಪದೇ. 32 ಬಾರಿ ಹೇಳೋಣ.

ಹೆಚ್ಚಿನ ಹೊರೆಯ ಬೇಡಿಕೆಗಳನ್ನು ಪೂರೈಸಲು RPC ಮೂಲಸೌಕರ್ಯವು ಹೇಗೆ ಗಮನಾರ್ಹವಾಗಿ ಸುಧಾರಿಸಿದೆ ಎಂಬುದನ್ನು ನೋಡಿ. ವಿಷಯವೆಂದರೆ REST RPC ಗಿಂತ ಭಿನ್ನವಾಗಿ HTTP ಪ್ರೋಟೋಕಾಲ್‌ನ ಸಂಪೂರ್ಣ ಶಕ್ತಿಯನ್ನು ಬಳಸುತ್ತದೆ. ಮೇಲಿನ ರೇಖಾಚಿತ್ರದಲ್ಲಿ, ವಿನಂತಿಯ ವಿಧಾನದ ಮೂಲಕ ಈ ಶಕ್ತಿಯನ್ನು ಅರಿತುಕೊಳ್ಳಲಾಗುತ್ತದೆ - GET.

HTTP ವಿಧಾನಗಳು, ಇತರ ವಿಷಯಗಳ ಜೊತೆಗೆ, ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವ ತಂತ್ರಗಳನ್ನು ಹೊಂದಿವೆ. ನೀವು ಅವುಗಳನ್ನು ದಸ್ತಾವೇಜನ್ನು ನಲ್ಲಿ ಕಾಣಬಹುದು HTTP. RPC ಗಾಗಿ, POST ವಿನಂತಿಗಳನ್ನು ಬಳಸಲಾಗುತ್ತದೆ, ಇವುಗಳನ್ನು ಅಸಮರ್ಥವೆಂದು ಪರಿಗಣಿಸಲಾಗುವುದಿಲ್ಲ, ಅಂದರೆ, ಅದೇ POST ವಿನಂತಿಗಳ ಪುನರಾವರ್ತಿತ ಪುನರಾವರ್ತನೆಗಳು ವಿಭಿನ್ನ ಫಲಿತಾಂಶಗಳನ್ನು ನೀಡಬಹುದು (ಉದಾಹರಣೆಗೆ, ಪ್ರತಿ ಕಾಮೆಂಟ್ ಕಳುಹಿಸಿದ ನಂತರ, ಈ ಕಾಮೆಂಟ್‌ನ ಮತ್ತೊಂದು ಪ್ರತಿಯು ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ) (ಮೂಲ).

ಪರಿಣಾಮವಾಗಿ, ಮೂಲಸೌಕರ್ಯ ಸಂಗ್ರಹಗಳನ್ನು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಬಳಸಲು RPC ಗೆ ಸಾಧ್ಯವಾಗುತ್ತಿಲ್ಲ. ಇದು ಸಾಫ್ಟ್‌ವೇರ್ ಕ್ಯಾಶ್‌ಗಳನ್ನು "ಆಮದು" ಮಾಡುವ ಅಗತ್ಯಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ. ರೇಖಾಚಿತ್ರವು ಈ ಪಾತ್ರದಲ್ಲಿ ರೆಡಿಸ್ ಅನ್ನು ತೋರಿಸುತ್ತದೆ. ಸಾಫ್ಟ್‌ವೇರ್ ಸಂಗ್ರಹಕ್ಕೆ, ಡೆವಲಪರ್‌ಗೆ ಹೆಚ್ಚುವರಿ ಕೋಡ್‌ನ ಲೇಯರ್ ಮತ್ತು ಆರ್ಕಿಟೆಕ್ಚರ್‌ನಲ್ಲಿ ಗಮನಾರ್ಹ ಬದಲಾವಣೆಗಳನ್ನು ಸೇರಿಸುವ ಅಗತ್ಯವಿದೆ.

ಪರಿಗಣನೆಯಲ್ಲಿರುವ ಮೂಲಸೌಕರ್ಯದಲ್ಲಿ REST ಮತ್ತು RPC ಎಷ್ಟು ವಿನಂತಿಗಳನ್ನು "ಜನ್ಮ ನೀಡಿದೆ" ಎಂದು ಈಗ ಎಣಿಸೋಣ?

ವಿನಂತಿಗಳನ್ನು
ಇನ್ಬಾಕ್ಸ್
ಬ್ಯಾಕೆಂಡ್ ಮಾಡಲು
DBMS ಗೆ
ಮೃದು ಸಂಗ್ರಹಕ್ಕೆ (ರೆಡಿಸ್)
TOTAL

ಉಳಿದ
1 / 32 *
1
1
0
3 / 35

ಆರ್ಪಿಸಿ
32
32
1
31
96

[*] ಉತ್ತಮ ಸಂದರ್ಭದಲ್ಲಿ (ಸ್ಥಳೀಯ ಸಂಗ್ರಹವನ್ನು ಬಳಸಿದರೆ) 1 ವಿನಂತಿ (ಒಂದು!), ಕೆಟ್ಟ ಸಂದರ್ಭದಲ್ಲಿ 32 ಒಳಬರುವ ವಿನಂತಿಗಳು.

ಮೊದಲ ಯೋಜನೆಗೆ ಹೋಲಿಸಿದರೆ, ವ್ಯತ್ಯಾಸವು ಗಮನಾರ್ಹವಾಗಿದೆ. ಈಗ REST ನ ಪ್ರಯೋಜನವು ಸ್ಪಷ್ಟವಾಗುತ್ತದೆ. ಆದರೆ ಅಲ್ಲಿ ನಿಲ್ಲದಂತೆ ನಾನು ಸಲಹೆ ನೀಡುತ್ತೇನೆ. ಅಭಿವೃದ್ಧಿ ಹೊಂದಿದ ಮೂಲಸೌಕರ್ಯವು CDN ಅನ್ನು ಒಳಗೊಂಡಿದೆ. ಆಗಾಗ್ಗೆ ಇದು DDoS ಮತ್ತು DoS ದಾಳಿಗಳನ್ನು ಎದುರಿಸುವ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುತ್ತದೆ. ನಾವು ಪಡೆಯುತ್ತೇವೆ:

RPC ಗೆ ವಿಷಯಗಳು ನಿಜವಾಗಿಯೂ ಕೆಟ್ಟದಾಗಿರುವುದು ಇಲ್ಲಿಯೇ. RPC ಕೇವಲ CDN ಗೆ ಕೆಲಸದ ಹೊರೆಯನ್ನು ನಿಯೋಜಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಹೊಂದಿಲ್ಲ. ದಾಳಿಗಳನ್ನು ಎದುರಿಸಲು ನಾವು ವ್ಯವಸ್ಥೆಗಳನ್ನು ಮಾತ್ರ ಅವಲಂಬಿಸಬಹುದು.

ಇಲ್ಲಿಗೆ ಮುಗಿಯಲು ಸಾಧ್ಯವೇ? ಮತ್ತು ಮತ್ತೆ, ಇಲ್ಲ. HTTP ವಿಧಾನಗಳು, ಮೇಲೆ ತಿಳಿಸಿದಂತೆ, ತಮ್ಮದೇ ಆದ "ಮ್ಯಾಜಿಕ್" ಅನ್ನು ಹೊಂದಿವೆ. ಮತ್ತು ಇಂಟರ್ನೆಟ್‌ನಲ್ಲಿ GET ವಿಧಾನವನ್ನು ವ್ಯಾಪಕವಾಗಿ ಬಳಸಲಾಗುತ್ತಿರುವುದು ಕಾರಣವಿಲ್ಲದೆ ಅಲ್ಲ. ಈ ವಿಧಾನವು ವಿಷಯದ ತುಣುಕನ್ನು ಪ್ರವೇಶಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಗಮನಿಸಿ, ನಿಮ್ಮ ಕೋಡ್‌ಗೆ ನಿಯಂತ್ರಣವನ್ನು ವರ್ಗಾಯಿಸುವ ಮೊದಲು ಮೂಲಸೌಕರ್ಯ ಅಂಶಗಳು ವ್ಯಾಖ್ಯಾನಿಸಬಹುದಾದ ಷರತ್ತುಗಳನ್ನು ಹೊಂದಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ, ಇತ್ಯಾದಿ. ವಿನಂತಿಗಳ ದೊಡ್ಡ ಹರಿವನ್ನು ನಿಭಾಯಿಸಬಲ್ಲ ಹೊಂದಿಕೊಳ್ಳುವ, ನಿರ್ವಹಿಸಬಹುದಾದ ಮೂಲಸೌಕರ್ಯಗಳನ್ನು ರಚಿಸಲು ಇವೆಲ್ಲವೂ ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಆದರೆ RPC ಯಲ್ಲಿ ಈ ವಿಧಾನವನ್ನು ನಿರ್ಲಕ್ಷಿಸಲಾಗುತ್ತದೆ.

ಹಾಗಾದರೆ ಬ್ಯಾಚ್ ವಿನಂತಿಗಳು (RPC) ವೇಗವಾಗಿರುತ್ತದೆ ಎಂಬ ಪುರಾಣವು ಏಕೆ ನಿರಂತರವಾಗಿದೆ? ವೈಯಕ್ತಿಕವಾಗಿ, ಹೆಚ್ಚಿನ ಯೋಜನೆಗಳು ಕೇವಲ REST ತನ್ನ ಶಕ್ತಿಯನ್ನು ತೋರಿಸಲು ಸಾಧ್ಯವಾಗುವ ಅಭಿವೃದ್ಧಿಯ ಮಟ್ಟವನ್ನು ತಲುಪುವುದಿಲ್ಲ ಎಂದು ನನಗೆ ತೋರುತ್ತದೆ. ಇದಲ್ಲದೆ, ಸಣ್ಣ ಯೋಜನೆಗಳಲ್ಲಿ, ಅವರು ತಮ್ಮ ದೌರ್ಬಲ್ಯಗಳನ್ನು ತೋರಿಸಲು ಹೆಚ್ಚು ಸಿದ್ಧರಿದ್ದಾರೆ.

REST ಅಥವಾ RPC ಯ ಆಯ್ಕೆಯು ಪ್ರಾಜೆಕ್ಟ್‌ನಲ್ಲಿ ವ್ಯಕ್ತಿಯ ಸ್ವಯಂಪ್ರೇರಿತ ಆಯ್ಕೆಯಲ್ಲ. ಈ ಆಯ್ಕೆಯು ಯೋಜನೆಯ ಅವಶ್ಯಕತೆಗಳನ್ನು ಪೂರೈಸಬೇಕು. ಯೋಜನೆಯು REST ನಿಂದ ನಿಜವಾಗಿಯೂ ಮಾಡಬಹುದಾದ ಎಲ್ಲವನ್ನೂ ಹಿಂಡಲು ಸಾಧ್ಯವಾದರೆ ಮತ್ತು ಅದಕ್ಕೆ ನಿಜವಾಗಿಯೂ ಅದು ಅಗತ್ಯವಿದ್ದರೆ, REST ಅತ್ಯುತ್ತಮ ಆಯ್ಕೆಯಾಗಿದೆ.

ಆದರೆ, REST ಯ ಎಲ್ಲಾ ಪ್ರಯೋಜನಗಳನ್ನು ಪಡೆಯಲು, ಮೂಲಸೌಕರ್ಯವನ್ನು ತ್ವರಿತವಾಗಿ ಅಳೆಯಲು ಪ್ರಾಜೆಕ್ಟ್‌ಗೆ ಡೆವೊಪ್ಸ್ ಪರಿಣಿತರನ್ನು, ಮೂಲಸೌಕರ್ಯವನ್ನು ನಿರ್ವಹಿಸಲು ನಿರ್ವಾಹಕರನ್ನು, ವೆಬ್ ಸೇವೆಯ ಎಲ್ಲಾ ಲೇಯರ್‌ಗಳನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸಲು ವಾಸ್ತುಶಿಲ್ಪಿ... ಮತ್ತು ಯೋಜನೆಗೆ ನೀವು ನೇಮಿಸಿಕೊಳ್ಳಬೇಕು. , ಅದೇ ಸಮಯದಲ್ಲಿ, ದಿನಕ್ಕೆ ಮೂರು ಪ್ಯಾಕ್ ಮಾರ್ಗರೀನ್ ಅನ್ನು ಮಾರಾಟ ಮಾಡುತ್ತದೆ ... ನಾನು RPC ಯೊಂದಿಗೆ ಅಂಟಿಕೊಳ್ಳುತ್ತೇನೆ, ಏಕೆಂದರೆ... ಈ ಪ್ರೋಟೋಕಾಲ್ ಹೆಚ್ಚು ಉಪಯುಕ್ತವಾಗಿದೆ. ಸಂಗ್ರಹಗಳು ಮತ್ತು ಮೂಲಸೌಕರ್ಯವು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದರ ಕುರಿತು ಆಳವಾದ ಜ್ಞಾನದ ಅಗತ್ಯವಿರುವುದಿಲ್ಲ, ಆದರೆ ಡೆವಲಪರ್ ಅವರಿಗೆ ಅಗತ್ಯವಿರುವ ಕಾರ್ಯವಿಧಾನಗಳಿಗೆ ಸರಳ ಮತ್ತು ಅರ್ಥವಾಗುವ ಕರೆಗಳ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸುತ್ತದೆ. ವ್ಯಾಪಾರ ಸಂತೋಷದಿಂದ ಕೂಡಿರುತ್ತದೆ.

RPC ವಿನಂತಿಗಳು ಹೆಚ್ಚು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿರುತ್ತವೆ ಏಕೆಂದರೆ ಅವುಗಳು ಒಂದೇ ವಹಿವಾಟಿನೊಳಗೆ ಬ್ಯಾಚ್ ವಿನಂತಿಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದು

RPC ಯ ಈ ಆಸ್ತಿಯು ಒಂದು ನಿರ್ದಿಷ್ಟ ಪ್ರಯೋಜನವಾಗಿದೆ, ಏಕೆಂದರೆ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಸ್ಥಿರವಾಗಿ ಇಡುವುದು ಸುಲಭ. ಆದರೆ REST ಯೊಂದಿಗೆ ಇದು ಹೆಚ್ಚು ಹೆಚ್ಚು ಜಟಿಲವಾಗಿದೆ. ವಿನಂತಿಗಳು ವಿಭಿನ್ನ ಬ್ಯಾಕೆಂಡ್ ನೋಡ್‌ಗಳಿಗೆ ಅಸಮಂಜಸವಾಗಿ ಬರಬಹುದು.

REST ನ ಈ "ಅನುಕೂಲವೆಂದರೆ" ಮೇಲೆ ವಿವರಿಸಿದ ಅದರ ಪ್ರಯೋಜನದ ಫ್ಲಿಪ್ ಸೈಡ್ ಆಗಿದೆ - ಎಲ್ಲಾ ಮೂಲಸೌಕರ್ಯ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಸಮರ್ಥವಾಗಿ ಬಳಸುವ ಸಾಮರ್ಥ್ಯ. ಮೂಲಸೌಕರ್ಯವನ್ನು ಕಳಪೆಯಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಿದ್ದರೆ, ಮತ್ತು ಅದಕ್ಕಿಂತ ಹೆಚ್ಚಾಗಿ ಯೋಜನೆಯ ವಾಸ್ತುಶಿಲ್ಪ ಮತ್ತು ನಿರ್ದಿಷ್ಟವಾಗಿ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಕಳಪೆಯಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಿದ್ದರೆ, ಇದು ನಿಜವಾಗಿಯೂ ದೊಡ್ಡ ನೋವು.

ಆದರೆ ಬ್ಯಾಚ್ ವಿನಂತಿಗಳು ತೋರುವಷ್ಟು ವಿಶ್ವಾಸಾರ್ಹವೇ? ಒಂದು ಪ್ರಕರಣವನ್ನು ನೋಡೋಣ: ನಾವು ಬಳಕೆದಾರರನ್ನು ರಚಿಸುತ್ತೇವೆ, ಕೆಲವು ವಿವರಣೆಯೊಂದಿಗೆ ಅವರ ಪ್ರೊಫೈಲ್ ಅನ್ನು ಉತ್ಕೃಷ್ಟಗೊಳಿಸುತ್ತೇವೆ ಮತ್ತು ನೋಂದಣಿಯನ್ನು ಪೂರ್ಣಗೊಳಿಸಲು ರಹಸ್ಯದೊಂದಿಗೆ SMS ಕಳುಹಿಸುತ್ತೇವೆ. ಆ. ಒಂದು ಬ್ಯಾಚ್ ವಿನಂತಿಯಲ್ಲಿ ಮೂರು ಕರೆಗಳು.

ರೇಖಾಚಿತ್ರವನ್ನು ನೋಡೋಣ. ಇದು ಹೆಚ್ಚಿನ ಲಭ್ಯತೆಯ ಅಂಶಗಳೊಂದಿಗೆ ಮೂಲಸೌಕರ್ಯವನ್ನು ಪ್ರಸ್ತುತಪಡಿಸುತ್ತದೆ. SMS ಗೇಟ್‌ವೇಗಳೊಂದಿಗೆ ಎರಡು ಸ್ವತಂತ್ರ ಸಂವಹನ ಚಾನೆಲ್‌ಗಳಿವೆ. ಆದರೆ ... ನಾವು ಏನು ನೋಡುತ್ತೇವೆ? SMS ಕಳುಹಿಸುವಾಗ, ದೋಷ 503 ಸಂಭವಿಸುತ್ತದೆ - ಸೇವೆಯು ತಾತ್ಕಾಲಿಕವಾಗಿ ಲಭ್ಯವಿಲ್ಲ. ಏಕೆಂದರೆ SMS ಕಳುಹಿಸುವಿಕೆಯನ್ನು ಬ್ಯಾಚ್ ವಿನಂತಿಯಲ್ಲಿ ಪ್ಯಾಕ್ ಮಾಡಲಾಗಿದೆ, ನಂತರ ಸಂಪೂರ್ಣ ವಿನಂತಿಯನ್ನು ಹಿಂತಿರುಗಿಸಬೇಕು. DBMS ನಲ್ಲಿನ ಕ್ರಿಯೆಗಳನ್ನು ರದ್ದುಗೊಳಿಸಲಾಗಿದೆ. ಕ್ಲೈಂಟ್ ದೋಷವನ್ನು ಸ್ವೀಕರಿಸುತ್ತಾನೆ.

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

ಸರಿ, ವಿನಂತಿಯನ್ನು ಭಾಗಶಃ ಯಶಸ್ವಿಯಾಗಿ ಪೂರ್ಣಗೊಳಿಸಿದಾಗ ನಾವು ನಮ್ಮನ್ನು (!) ಮತ್ತು ಆಯ್ಕೆಯ ಮೂಲಕ ಯೋಚಿಸಿದ್ದೇವೆ ಎಂದು ಊಹಿಸೋಣ. ಮತ್ತು ನಾವು ಸ್ವಲ್ಪ ಸಮಯದ ಮಧ್ಯಂತರದ ನಂತರ ಮತ್ತೆ ಉಳಿದವನ್ನು ಪೂರ್ಣಗೊಳಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತೇವೆ (ಯಾವುದು? ಮುಂಭಾಗವು ನಿರ್ಧರಿಸುತ್ತದೆಯೇ?). ಆದರೆ ಲಾಟರಿ ಹಾಗೇ ಇತ್ತು. SMS ಕಳುಹಿಸಲು ವಿನಂತಿಯು ಮತ್ತೊಮ್ಮೆ ವಿಫಲಗೊಳ್ಳುವ 50/50 ಅವಕಾಶವನ್ನು ಹೊಂದಿದೆ.

ಒಪ್ಪುತ್ತೇನೆ, ಕ್ಲೈಂಟ್ ಕಡೆಯಿಂದ, ಸೇವೆಯು ನಾವು ಬಯಸಿದಷ್ಟು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿ ತೋರುತ್ತಿಲ್ಲ ... REST ಬಗ್ಗೆ ಏನು?

REST ಮತ್ತೆ HTTP ಯ ಮ್ಯಾಜಿಕ್ ಅನ್ನು ಬಳಸುತ್ತದೆ, ಆದರೆ ಈಗ ಪ್ರತಿಕ್ರಿಯೆ ಕೋಡ್‌ಗಳೊಂದಿಗೆ. SMS ಗೇಟ್‌ವೇಯಲ್ಲಿ ದೋಷ 503 ಸಂಭವಿಸಿದಾಗ, ಬ್ಯಾಲೆನ್ಸರ್‌ಗೆ ಬ್ಯಾಕೆಂಡ್ ಈ ದೋಷವನ್ನು ಪ್ರಸಾರ ಮಾಡುತ್ತದೆ. ಬ್ಯಾಲೆನ್ಸರ್ ಈ ದೋಷವನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ ಮತ್ತು ಕ್ಲೈಂಟ್ನೊಂದಿಗೆ ಸಂಪರ್ಕವನ್ನು ಮುರಿಯದೆಯೇ, ವಿನಂತಿಯನ್ನು ಮತ್ತೊಂದು ನೋಡ್ಗೆ ಕಳುಹಿಸುತ್ತದೆ, ಅದು ವಿನಂತಿಯನ್ನು ಯಶಸ್ವಿಯಾಗಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ. ಆ. ಕ್ಲೈಂಟ್ ನಿರೀಕ್ಷಿತ ಫಲಿತಾಂಶವನ್ನು ಪಡೆಯುತ್ತದೆ ಮತ್ತು ಮೂಲಸೌಕರ್ಯವು ಅದರ "ಹೆಚ್ಚು ಸುಲಭವಾಗಿ ಪ್ರವೇಶಿಸಬಹುದಾದ" ಶೀರ್ಷಿಕೆಯನ್ನು ಖಚಿತಪಡಿಸುತ್ತದೆ. ಬಳಕೆದಾರ ಸಂತೋಷವಾಗಿದೆ.

ಮತ್ತೆ ಅಷ್ಟೇ ಅಲ್ಲ. ಬ್ಯಾಲೆನ್ಸರ್ ಕೇವಲ 503 ರ ಪ್ರತಿಕ್ರಿಯೆ ಕೋಡ್ ಅನ್ನು ಸ್ವೀಕರಿಸಲಿಲ್ಲ. ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಪ್ರಕಾರ ಪ್ರತಿಕ್ರಿಯಿಸುವಾಗ, "ಮರುಪ್ರಯತ್ನ-ನಂತರ" ಹೆಡರ್ನೊಂದಿಗೆ ಈ ಕೋಡ್ ಅನ್ನು ಒದಗಿಸುವುದು ಸೂಕ್ತವಾಗಿದೆ. ನಿರ್ದಿಷ್ಟ ಸಮಯಕ್ಕೆ ಈ ಮಾರ್ಗದಲ್ಲಿ ಈ ನೋಡ್ ಅನ್ನು ತೊಂದರೆಗೊಳಿಸುವುದು ಯೋಗ್ಯವಾಗಿಲ್ಲ ಎಂದು ಹೆಡರ್ ಬ್ಯಾಲೆನ್ಸರ್ಗೆ ಸ್ಪಷ್ಟಪಡಿಸುತ್ತದೆ. ಮತ್ತು SMS ಕಳುಹಿಸಲು ಮುಂದಿನ ವಿನಂತಿಗಳನ್ನು SMS ಗೇಟ್‌ವೇಯಲ್ಲಿ ಯಾವುದೇ ತೊಂದರೆಗಳಿಲ್ಲದ ನೋಡ್‌ಗೆ ನೇರವಾಗಿ ಕಳುಹಿಸಲಾಗುತ್ತದೆ.

ನಾವು ನೋಡುವಂತೆ, JSON-RPC ಯ ವಿಶ್ವಾಸಾರ್ಹತೆಯನ್ನು ಅತಿಯಾಗಿ ಅಂದಾಜು ಮಾಡಲಾಗಿದೆ. ವಾಸ್ತವವಾಗಿ, ಡೇಟಾಬೇಸ್ನಲ್ಲಿ ಸ್ಥಿರತೆಯನ್ನು ಸಂಘಟಿಸಲು ಸುಲಭವಾಗಿದೆ. ಆದರೆ ತ್ಯಾಗ, ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಒಟ್ಟಾರೆಯಾಗಿ ವ್ಯವಸ್ಥೆಯ ವಿಶ್ವಾಸಾರ್ಹತೆ ಇರುತ್ತದೆ.

ತೀರ್ಮಾನವು ಹಿಂದಿನದಕ್ಕೆ ಹೆಚ್ಚಾಗಿ ಹೋಲುತ್ತದೆ. ಮೂಲಸೌಕರ್ಯವು ಸರಳವಾದಾಗ, JSON-RPC ಯ ಸ್ಪಷ್ಟತೆಯು ಖಂಡಿತವಾಗಿಯೂ ಒಂದು ಪ್ಲಸ್ ಆಗಿದೆ. ಯೋಜನೆಯು ಹೆಚ್ಚಿನ ಹೊರೆಯೊಂದಿಗೆ ಹೆಚ್ಚಿನ ಲಭ್ಯತೆಯನ್ನು ಒಳಗೊಂಡಿದ್ದರೆ, REST ಹೆಚ್ಚು ಸರಿಯಾಗಿ ಕಾಣುತ್ತದೆ, ಆದರೂ ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾದ ಪರಿಹಾರವಾಗಿದೆ.

REST ಗೆ ಪ್ರವೇಶ ಮಿತಿ ಕಡಿಮೆಯಾಗಿದೆ

ಮೇಲಿನ ವಿಶ್ಲೇಷಣೆಯು RPC ಯ ಬಗ್ಗೆ ಸ್ಥಾಪಿತವಾದ ಸ್ಟೀರಿಯೊಟೈಪ್‌ಗಳನ್ನು ಡಿಬಂಕ್ ಮಾಡುವುದರಿಂದ, REST ಗೆ ಪ್ರವೇಶದ ಮಿತಿಯು RPC ಗಿಂತ ನಿಸ್ಸಂದೇಹವಾಗಿ ಹೆಚ್ಚಾಗಿದೆ ಎಂದು ಸ್ಪಷ್ಟವಾಗಿ ತೋರಿಸಿದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ಇದು HTTP ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದರ ಆಳವಾದ ತಿಳುವಳಿಕೆಯ ಅಗತ್ಯತೆಯಿಂದಾಗಿ, ಹಾಗೆಯೇ ವೆಬ್ ಯೋಜನೆಗಳಲ್ಲಿ ಬಳಸಬಹುದಾದ ಮತ್ತು ಬಳಸಬೇಕಾದ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಮೂಲಸೌಕರ್ಯ ಅಂಶಗಳ ಬಗ್ಗೆ ಸಾಕಷ್ಟು ಜ್ಞಾನವನ್ನು ಹೊಂದಿರುವುದು ಅಗತ್ಯವಾಗಿದೆ.

ಹಾಗಾದರೆ REST ಸರಳವಾಗಿದೆ ಎಂದು ಅನೇಕ ಜನರು ಏಕೆ ಭಾವಿಸುತ್ತಾರೆ? ಈ ಸ್ಪಷ್ಟವಾದ ಸರಳತೆಯು REST ಮ್ಯಾನಿಫೆಸ್ಟ್‌ಗಳಿಂದ ಬಂದಿದೆ ಎಂಬುದು ನನ್ನ ವೈಯಕ್ತಿಕ ಅಭಿಪ್ರಾಯ. ಆ. REST ಒಂದು ಪ್ರೋಟೋಕಾಲ್ ಅಲ್ಲ ಆದರೆ ಒಂದು ಪರಿಕಲ್ಪನೆಯಾಗಿದೆ... REST ಒಂದು ಮಾನದಂಡವನ್ನು ಹೊಂದಿಲ್ಲ, ಕೆಲವು ಮಾರ್ಗಸೂಚಿಗಳಿವೆ... REST HTTP ಗಿಂತ ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಗಿಲ್ಲ. ಸ್ಪಷ್ಟವಾದ ಸ್ವಾತಂತ್ರ್ಯ ಮತ್ತು ಅರಾಜಕತೆ "ಮುಕ್ತ ಕಲಾವಿದರನ್ನು" ಆಕರ್ಷಿಸುತ್ತದೆ.

ಸಹಜವಾಗಿ, REST HTTP ಗಿಂತ ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಗಿಲ್ಲ. ಆದರೆ HTTP ಸ್ವತಃ ಉತ್ತಮವಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾದ ಪ್ರೋಟೋಕಾಲ್ ಆಗಿದ್ದು ಅದು ದಶಕಗಳಿಂದ ಅದರ ಮೌಲ್ಯವನ್ನು ಸಾಬೀತುಪಡಿಸಿದೆ. HTTP ಯ ಬಗ್ಗೆ ಯಾವುದೇ ಆಳವಾದ ತಿಳುವಳಿಕೆ ಇಲ್ಲದಿದ್ದರೆ, ನಂತರ REST ಅನ್ನು ನಿರ್ಣಯಿಸಲಾಗುವುದಿಲ್ಲ.

ಆದರೆ RPC ಬಗ್ಗೆ - ನೀವು ಮಾಡಬಹುದು. ಅದರ ವಿವರಣೆಯನ್ನು ತೆಗೆದುಕೊಂಡರೆ ಸಾಕು. ಆದ್ದರಿಂದ ನಿಮಗೆ ಅಗತ್ಯವಿದೆಯೇ ಮೂರ್ಖ JSON-RPC? ಅಥವಾ ಇದು ಇನ್ನೂ ಟ್ರಿಕಿ REST ಆಗಿದೆಯೇ? ನೀನು ನಿರ್ಧರಿಸು.

ನಾನು ನಿಮ್ಮ ಸಮಯವನ್ನು ವ್ಯರ್ಥ ಮಾಡಿಲ್ಲ ಎಂದು ನಾನು ಪ್ರಾಮಾಣಿಕವಾಗಿ ಭಾವಿಸುತ್ತೇನೆ.

ಮೂಲ: www.habr.com