JSON-RPC? យក REST ដ៏លំបាក

ខ្ញុំ​ប្រាកដ​ថា​ចំណង​ជើង​នេះ​បាន​បង្ក​ឱ្យ​មាន​ប្រតិកម្ម​ដែល​មាន​សុខភាព​ល្អ - "មែន​ហើយ វា​បាន​ចាប់​ផ្តើម​ម្តង​ទៀត...

រចនាសម្ព័ននៃអត្ថបទនឹងមានដូចខាងក្រោម៖ សេចក្តីថ្លែងការណ៍គំរូមួយត្រូវបានយក ហើយ "ធម្មជាតិ" នៃការកើតឡើងនៃគំរូនេះត្រូវបានបង្ហាញ។ ខ្ញុំសង្ឃឹមថាវានឹងអនុញ្ញាតឱ្យអ្នកមើលជម្រើសនៃគំរូផ្លាស់ប្តូរទិន្នន័យនៅក្នុងគម្រោងរបស់អ្នកពីមុំថ្មីមួយ។

ដើម្បីអោយច្បាស់អំពីអ្វីដែលជា RPC ខ្ញុំស្នើឱ្យពិចារណាស្តង់ដារ JSON-RPC 2.0. ជាមួយ REST មិនមានភាពច្បាស់លាស់ទេ។ ហើយវាមិនគួរទេ។ អ្វីគ្រប់យ៉ាងដែលអ្នកត្រូវដឹងអំពី REST - វាមិនអាចបែងចែកបានទេ។ របស់ HTTP.

សំណើ RPC កាន់តែលឿន និងមានប្រសិទ្ធភាពជាងមុន ព្រោះវាអនុញ្ញាតឱ្យអ្នកធ្វើសំណើជាបាច់។

ចំណុចគឺថានៅក្នុង RPC អ្នកអាចហៅនីតិវិធីជាច្រើនក្នុងពេលតែមួយក្នុងសំណើមួយ។ ជាឧទាហរណ៍ បង្កើតអ្នកប្រើប្រាស់ បន្ថែមរូបតំណាងឱ្យគាត់ ហើយក្នុងសំណើដូចគ្នានេះ ជាវគាត់ទៅប្រធានបទមួយចំនួន។ សុំតែមួយប៉ុណ្ណឹង ចំណេញប៉ុន្មាន!

ជាការពិតណាស់ ប្រសិនបើអ្នកមានថ្នាំងផ្នែកខាងក្រោយតែមួយ វានឹងហាក់ដូចជាលឿនជាងមុនជាមួយនឹងសំណើជាបាច់។ ដោយសារតែសំណើ REST បីនឹងត្រូវការធនធានបីដងបន្ថែមទៀតពីថ្នាំងមួយដើម្បីបង្កើតការតភ្ជាប់។

ចំណាំថាសំណើដំបូងក្នុងករណី REST ត្រូវតែប្រគល់លេខសម្គាល់អ្នកប្រើប្រាស់វិញដើម្បីឱ្យសំណើជាបន្តបន្ទាប់ត្រូវបានធ្វើឡើង។ ដែលជះឥទ្ធិពលអវិជ្ជមានដល់លទ្ធផលទាំងមូលផងដែរ។

ប៉ុន្តែហេដ្ឋារចនាសម្ព័ន្ធបែបនេះអាចរកបានតែនៅក្នុងដំណោះស្រាយក្នុងផ្ទះ និងសហគ្រាសប៉ុណ្ណោះ។ ជាមធ្យោបាយចុងក្រោយនៅក្នុងគម្រោងបណ្តាញតូចៗ។ ប៉ុន្តែដំណោះស្រាយ WEB ពេញលេញ និងសូម្បីតែអ្នកដែលហៅថា HighLoad គឺមិនមានតម្លៃក្នុងការបង្កើតនោះទេ។ ហេដ្ឋារចនាសម្ព័ន្ធរបស់ពួកគេត្រូវតែបំពេញតាមលក្ខណៈវិនិច្ឆ័យនៃភាពអាចរកបាន និងបន្ទុកខ្ពស់។ ហើយរូបភាពកំពុងផ្លាស់ប្តូរ។

បណ្តាញសកម្មភាពហេដ្ឋារចនាសម្ព័ន្ធនៅក្រោមសេណារីយ៉ូដូចគ្នាត្រូវបានសម្គាល់ជាពណ៌បៃតង។ សូមកត់សម្គាល់ពីរបៀបដែល RPC ប្រព្រឹត្តឥឡូវនេះ។ សំណើប្រើប្រាស់ហេដ្ឋារចនាសម្ព័ន្ធនៅលើជើងតែមួយ ពីឧបករណ៍តុល្យភាពទៅផ្នែកខាងក្រោយ។ ខណៈពេលដែល REST នៅតែចាញ់នៅក្នុងសំណើដំបូង វាបង្កើតពេលវេលាដែលបាត់បង់ដោយប្រើហេដ្ឋារចនាសម្ព័ន្ធទាំងមូល។

វាគ្រប់គ្រាន់ហើយក្នុងការចូលទៅក្នុងស្គ្រីបមិនមែនជាសំណើពីរសម្រាប់ការពង្រឹងទេ ប៉ុន្តែនិយាយថា ប្រាំ ឬដប់... និងចម្លើយចំពោះសំណួរ "តើអ្នកណាឈ្នះឥឡូវនេះ?" ក្លាយជាមិនច្បាស់លាស់។

ខ្ញុំស្នើឱ្យពិនិត្យឱ្យបានទូលំទូលាយលើបញ្ហា។ ដ្យាក្រាមបង្ហាញពីរបៀបដែលបណ្តាញហេដ្ឋារចនាសម្ព័ន្ធត្រូវបានប្រើប្រាស់ ប៉ុន្តែហេដ្ឋារចនាសម្ព័ន្ធមិនត្រូវបានកំណត់ចំពោះប៉ុស្តិ៍នោះទេ។ ធាតុផ្សំសំខាន់នៃហេដ្ឋារចនាសម្ព័ន្ធផ្ទុកខ្ពស់គឺឃ្លាំងសម្ងាត់។ ឥឡូវនេះ ចូរយើងទទួលបានប្រភេទនៃវត្ថុបុរាណអ្នកប្រើប្រាស់មួយចំនួន។ ម្តងហើយម្តងទៀត។ ចូរនិយាយថា 32 ដង។

សូមមើលពីរបៀបដែលហេដ្ឋារចនាសម្ព័ន្ធ RPC មានភាពប្រសើរឡើងយ៉ាងខ្លាំង ដើម្បីបំពេញតម្រូវការនៃបន្ទុកខ្ពស់។ រឿងនេះគឺថា REST ប្រើថាមពលពេញលេញនៃពិធីការ HTTP មិនដូច RPC ទេ។ នៅក្នុងដ្យាក្រាមខាងលើ អំណាចនេះត្រូវបានដឹងតាមរយៈវិធីសាស្ត្រស្នើសុំ - GET។

វិធីសាស្ត្រ HTTP ក្នុងចំណោមរបស់ផ្សេងទៀត មានយុទ្ធសាស្រ្តឃ្លាំងសម្ងាត់។ អ្នកអាចស្វែងរកពួកវានៅក្នុងឯកសារនៅ របស់ HTTP. សម្រាប់ RPC សំណើ POST ត្រូវបានប្រើ ដែលមិនត្រូវបានចាត់ទុកថាគ្មានប្រសិទ្ធភាព ពោលគឺការដដែលៗនៃសំណើ POST ដូចគ្នាអាចផ្តល់លទ្ធផលខុសៗគ្នា (ឧទាហរណ៍ បន្ទាប់ពីមតិយោបល់នីមួយៗត្រូវបានផ្ញើ ច្បាប់ចម្លងផ្សេងទៀតនៃមតិយោបល់នេះនឹងបង្ហាញ) (ប្រភព).

ជាលទ្ធផល RPC មិនអាចប្រើប្រាស់ឃ្លាំងសម្ងាត់ហេដ្ឋារចនាសម្ព័ន្ធប្រកបដោយប្រសិទ្ធភាព។ នេះនាំឱ្យមានតម្រូវការ "នាំចូល" ឃ្លាំងសម្ងាត់កម្មវិធី។ ដ្យាក្រាមបង្ហាញ Redis ក្នុងតួនាទីនេះ។ ជារួម ឃ្លាំងសម្ងាត់កម្មវិធីតម្រូវឱ្យអ្នកអភិវឌ្ឍន៍បន្ថែមស្រទាប់កូដបន្ថែម និងការផ្លាស់ប្តូរគួរឱ្យកត់សម្គាល់នៅក្នុងស្ថាបត្យកម្ម។

ឥឡូវនេះ ចូរយើងរាប់ថាតើសំណើ REST និង RPC "បានផ្តល់កំណើត" ចំនួនប៉ុន្មាននៅក្នុងហេដ្ឋារចនាសម្ព័ន្ធដែលកំពុងពិចារណា?

សំណើ
ប្រអប់ទទួល
ទៅខាងក្រោយ
ទៅ DBMS
ទៅឃ្លាំងសម្ងាត់ទន់ (Redis)
សរុប

សម្រាក
1 / 32 *
1
1
0
3 / 35

RPC
32
32
1
31
96

[*] ក្នុងករណីដ៏ល្អបំផុត (ប្រសិនបើឃ្លាំងសម្ងាត់មូលដ្ឋានត្រូវបានប្រើ) 1 សំណើ (មួយ!) ក្នុងករណីដ៏អាក្រក់បំផុត 32 សំណើចូល។

បើប្រៀបធៀបទៅនឹងគ្រោងការណ៍ទី 1 ភាពខុសគ្នាគឺគួរអោយចាប់អារម្មណ៍។ ឥឡូវនេះអត្ថប្រយោជន៍នៃ REST កាន់តែច្បាស់។ ប៉ុន្តែខ្ញុំស្នើកុំឈប់នៅទីនោះ។ ហេដ្ឋារចនាសម្ព័ន្ធដែលបានអភិវឌ្ឍរួមមាន CDN ។ ជាញឹកញាប់ វាក៏ដោះស្រាយបញ្ហានៃការប្រឆាំងការវាយប្រហារ DDoS និង DoS ផងដែរ។ យើង​ទទួល​បាន:

នេះគឺជាកន្លែងដែលអ្វីៗពិតជាអាក្រក់សម្រាប់ RPC ។ RPC មិនអាចផ្ទេរបន្ទុកការងារទៅ CDN បានទេ។ យើងអាចពឹងផ្អែកលើប្រព័ន្ធដើម្បីប្រឆាំងការវាយប្រហារតែប៉ុណ្ណោះ។

តើអាចបញ្ចប់នៅទីនេះបានទេ? ហើយម្តងទៀតទេ។ វិធីសាស្ត្រ HTTP ដូចដែលបានរៀបរាប់ខាងលើមាន "វេទមន្ត" ផ្ទាល់ខ្លួន។ ហើយវាមិនមែនដោយគ្មានហេតុផលទេដែលវិធីសាស្ត្រ GET ត្រូវបានប្រើប្រាស់យ៉ាងទូលំទូលាយនៅលើអ៊ីនធឺណិត។ ចំណាំថាវិធីសាស្ត្រនេះអាចចូលប្រើខ្លឹមសារមួយដុំ អាចកំណត់លក្ខខណ្ឌដែលធាតុហេដ្ឋារចនាសម្ព័ន្ធអាចបកស្រាយ មុនពេលការគ្រប់គ្រងត្រូវបានផ្ទេរទៅកូដរបស់អ្នក ហើយដូច្នេះនៅលើ។ ទាំងអស់នេះអនុញ្ញាតឱ្យអ្នកបង្កើតហេដ្ឋារចនាសម្ព័ន្ធដែលអាចបត់បែនបាន និងអាចគ្រប់គ្រងបាន ដែលអាចគ្រប់គ្រងលំហូរដ៏ធំនៃសំណើ។ ប៉ុន្តែនៅក្នុង RPC វិធីសាស្រ្តនេះ ... មិនត្រូវបានអើពើ។

ដូច្នេះហេតុអ្វីបានជាទេវកថាដែលសំណើជាបាច់ (RPC) លឿនជាងនេះ? ដោយផ្ទាល់ វាហាក់ដូចជាខ្ញុំថាគម្រោងភាគច្រើនមិនឈានដល់កម្រិតនៃការអភិវឌ្ឍន៍ដែល REST អាចបង្ហាញពីភាពខ្លាំងរបស់វា។ ជាងនេះទៅទៀត ក្នុងគម្រោងតូចៗ គាត់កាន់តែមានឆន្ទៈក្នុងការបង្ហាញពីភាពទន់ខ្សោយរបស់គាត់។

ជម្រើសនៃ REST ឬ RPC មិនមែនជាជម្រើសតាមឆន្ទៈរបស់បុគ្គលម្នាក់នៅក្នុងគម្រោងនោះទេ។ ជម្រើសនេះត្រូវតែបំពេញតាមតម្រូវការរបស់គម្រោង។ ប្រសិនបើគម្រោងមួយអាចច្របាច់អ្វីៗគ្រប់យ៉ាងចេញពី REST ហើយវាពិតជាត្រូវការវា នោះ REST នឹងក្លាយជាជម្រើសដ៏ល្អ។

ប៉ុន្តែប្រសិនបើ ដើម្បីទទួលបានអត្ថប្រយោជន៍ទាំងអស់ពី REST អ្នកត្រូវជួលអ្នកឯកទេស devops សម្រាប់គម្រោងដើម្បីពង្រីកហេដ្ឋារចនាសម្ព័ន្ធយ៉ាងឆាប់រហ័ស អ្នកគ្រប់គ្រងដើម្បីគ្រប់គ្រងហេដ្ឋារចនាសម្ព័ន្ធ ស្ថាបត្យករដើម្បីរចនាគ្រប់ស្រទាប់នៃសេវាកម្ម WEB ... និងគម្រោង។ ក្នុងពេលជាមួយគ្នានេះ លក់ម៉ាហ្គារីនបីកញ្ចប់ក្នុងមួយថ្ងៃ... ខ្ញុំនឹងនៅជាប់នឹង RPC ព្រោះ... ពិធីការនេះគឺមានប្រយោជន៍ជាង។ វានឹងមិនត្រូវការចំណេះដឹងជ្រៅជ្រះអំពីរបៀបដែលឃ្លាំងសម្ងាត់ និងហេដ្ឋារចនាសម្ព័ន្ធដំណើរការនោះទេ ប៉ុន្តែនឹងផ្តោតលើអ្នកអភិវឌ្ឍន៍លើការហៅទូរសព្ទសាមញ្ញ និងអាចយល់បានចំពោះនីតិវិធីដែលគាត់ត្រូវការ។ អាជីវកម្មនឹងសប្បាយចិត្ត។

សំណើ RPC មានភាពជឿជាក់ជាងមុន ដោយសារពួកគេអាចប្រតិបត្តិសំណើជាបាច់ក្នុងប្រតិបត្តិការតែមួយ

ទ្រព្យសម្បត្តិរបស់ RPC នេះគឺជាអត្ថប្រយោជន៍ច្បាស់លាស់មួយ ពីព្រោះ វាងាយស្រួលក្នុងការរក្សាមូលដ្ឋានទិន្នន័យឱ្យស្រប។ ប៉ុន្តែជាមួយនឹង REST វាកាន់តែស្មុគស្មាញ។ សំណើ​អាច​នឹង​មក​ដល់​ថ្នាំង​ខាង​ក្រោយ​ផ្សេង​គ្នា​ដោយ​មិន​ស្រប​គ្នា។

"គុណវិបត្តិ" នៃ REST នេះគឺជាផ្នែកត្រឡប់នៃអត្ថប្រយោជន៍របស់វាដែលបានពិពណ៌នាខាងលើ - សមត្ថភាពក្នុងការប្រើប្រាស់ធនធានហេដ្ឋារចនាសម្ព័ន្ធទាំងអស់ប្រកបដោយប្រសិទ្ធភាព។ ប្រសិនបើហេដ្ឋារចនាសម្ព័ន្ធត្រូវបានរចនាមិនសូវល្អ ហើយលើសពីនេះទៅទៀត ប្រសិនបើស្ថាបត្យកម្មនៃគម្រោង និងមូលដ្ឋានទិន្នន័យជាពិសេសត្រូវបានរចនាមិនល្អនោះ នេះពិតជាការឈឺចាប់ដ៏ធំមួយ។

ប៉ុន្តែ​តើ​សំណើ​ជា​បាច់​អាច​ទុក​ចិត្ត​បាន​ដូច​ដែល​ពួកគេ​មើល​ឃើញ​ដែរ​ឬ​ទេ? សូមក្រឡេកមើលករណីមួយ៖ យើងបង្កើតអ្នកប្រើប្រាស់ ពង្រីកប្រវត្តិរូបរបស់គាត់ជាមួយនឹងការពិពណ៌នាខ្លះៗ ហើយផ្ញើ SMS ទៅកាន់គាត់ដោយសម្ងាត់ដើម្បីបញ្ចប់ការចុះឈ្មោះ។ ទាំងនោះ។ ការហៅទូរស័ព្ទចំនួនបីក្នុងសំណើរមួយបាច់។

សូមក្រឡេកមើលដ្យាក្រាម។ វាបង្ហាញពីហេដ្ឋារចនាសម្ព័ន្ធដែលមានធាតុដែលអាចរកបានខ្ពស់។ មានបណ្តាញទំនាក់ទំនងឯករាជ្យពីរដែលមានច្រកផ្លូវ SMS ។ ប៉ុន្តែតើយើងឃើញអ្វី? នៅពេលផ្ញើសារ SMS កំហុស 503 កើតឡើង - សេវាកម្មមិនអាចប្រើបានជាបណ្តោះអាសន្ន។ ដោយសារតែ ការផ្ញើសារ SMS ត្រូវបានខ្ចប់ក្នុងសំណើជាបាច់ បន្ទាប់មកសំណើទាំងមូលត្រូវតែត្រលប់មកវិញ។ សកម្មភាពនៅក្នុង DBMS ត្រូវបានលុបចោល។ អតិថិជនទទួលបានកំហុស។

ការសាកល្បងបន្ទាប់គឺឆ្នោត។ ទាំងសំណើនឹងប៉ះថ្នាំងដូចគ្នាម្តងហើយម្តងទៀត ត្រឡប់កំហុស ឬអ្នកនឹងមានសំណាង ហើយវានឹងត្រូវបានប្រតិបត្តិ។ ប៉ុន្តែរឿងសំខាន់គឺថា យ៉ាងហោចណាស់នៅពេលដែលហេដ្ឋារចនាសម្ព័ន្ធរបស់យើងបានដំណើរការដោយឥតប្រយោជន៍រួចហើយ។ មានបន្ទុកប៉ុន្តែមិនចំណេញទេ។

មិនអីទេ ចូរយើងស្រមៃថាយើងបានធ្វើឱ្យខ្លួនយើងមានការតឹងតែង (!) ហើយគិតតាមរយៈជម្រើស នៅពេលដែលសំណើអាចត្រូវបានបញ្ចប់ដោយផ្នែកដោយជោគជ័យ។ ហើយ​យើង​នឹង​ព្យាយាម​បំពេញ​អ្វី​ដែល​នៅ​សល់​ម្ដង​ទៀត​បន្ទាប់​ពី​ចន្លោះ​ពេល​ខ្លះ (មួយ​ណា? ប៉ុន្តែឆ្នោតនៅតែដដែល។ សំណើដើម្បីផ្ញើសារ SMS មានឱកាស 50/50 នៃការបរាជ័យម្តងទៀត។

យល់ស្រប ពីខាងអតិថិជន សេវាហាក់ដូចជាមិនគួរឱ្យទុកចិត្តដូចដែលយើងចង់បាន... ចុះ REST វិញ?

REST ប្រើវេទមន្តនៃ HTTP ម្តងទៀត ប៉ុន្តែឥឡូវនេះជាមួយនឹងលេខកូដឆ្លើយតប។ នៅពេលដែលកំហុស 503 កើតឡើងនៅលើច្រក SMS ផ្នែកខាងក្រោយបានផ្សាយកំហុសនេះទៅកាន់ឧបករណ៍តុល្យភាព។ តុល្យការទទួលបានកំហុសនេះហើយដោយមិនបំបែកការតភ្ជាប់ជាមួយអតិថិជន ផ្ញើសំណើទៅកាន់ថ្នាំងផ្សេងទៀត ដែលដំណើរការសំណើដោយជោគជ័យ។ ទាំងនោះ។ អតិថិជនទទួលបានលទ្ធផលដែលរំពឹងទុក ហើយហេដ្ឋារចនាសម្ព័ន្ធបញ្ជាក់ពីចំណងជើងខ្ពស់របស់វាថា "អាចចូលដំណើរការបានខ្ពស់"។ អ្នកប្រើប្រាស់សប្បាយចិត្ត។

ហើយម្តងទៀតនោះមិនមែនទាំងអស់ទេ។ តុល្យការមិនគ្រាន់តែទទួលបានលេខកូដឆ្លើយតប 503 ទេ។ នៅពេលឆ្លើយតប យោងទៅតាមស្តង់ដារ វាត្រូវបានណែនាំឱ្យផ្តល់លេខកូដនេះជាមួយនឹងបឋមកថា "ព្យាយាមម្តងទៀតបន្ទាប់ពី" ។ បឋមកថាធ្វើឱ្យវាច្បាស់ដល់តុល្យភាពថាវាមិនមានតម្លៃរំខានថ្នាំងនេះនៅលើផ្លូវនេះសម្រាប់រយៈពេលជាក់លាក់មួយ។ ហើយសំណើបន្ទាប់ដើម្បីផ្ញើសារ SMS នឹងត្រូវបានផ្ញើដោយផ្ទាល់ទៅ node ដែលមិនមានបញ្ហាជាមួយ SMS gateway ។

ដូចដែលយើងអាចមើលឃើញ ភាពជឿជាក់នៃ JSON-RPC ត្រូវបានវាយតម្លៃលើស។ ជាការពិត វាកាន់តែងាយស្រួលក្នុងការរៀបចំភាពស៊ីសង្វាក់គ្នានៅក្នុងមូលដ្ឋានទិន្នន័យ។ ប៉ុន្តែការលះបង់ក្នុងករណីនេះនឹងក្លាយជាភាពជឿជាក់នៃប្រព័ន្ធទាំងមូល។

ការ​សន្និដ្ឋាន​គឺ​ស្រដៀង​គ្នា​នឹង​ការ​លើក​មុន​។ នៅពេលដែលហេដ្ឋារចនាសម្ព័ន្ធគឺសាមញ្ញ ភាពជាក់ស្តែងនៃ JSON-RPC គឺពិតជាបូកមួយ។ ប្រសិនបើគម្រោងពាក់ព័ន្ធនឹងភាពអាចរកបានខ្ពស់ជាមួយនឹងបន្ទុកខ្ពស់ REST មើលទៅដូចជាត្រឹមត្រូវជាង បើទោះបីជាដំណោះស្រាយកាន់តែស្មុគស្មាញក៏ដោយ។

កម្រិតចូល REST គឺទាបជាង

ខ្ញុំគិតថាការវិភាគខាងលើដោយបំបាត់នូវគំរូដែលបានបង្កើតឡើងអំពី RPC បានបង្ហាញយ៉ាងច្បាស់ថាកម្រិតនៃការចូលទៅក្នុង REST គឺពិតជាខ្ពស់ជាងការចូលទៅក្នុង RPC ។ នេះគឺដោយសារតែតម្រូវការសម្រាប់ការយល់ដឹងយ៉ាងស៊ីជម្រៅអំពីរបៀបដែល HTTP ដំណើរការ ក៏ដូចជាតម្រូវការដើម្បីឱ្យមានចំណេះដឹងគ្រប់គ្រាន់អំពីធាតុហេដ្ឋារចនាសម្ព័ន្ធដែលមានស្រាប់ដែលអាច និងគួរប្រើនៅក្នុងគម្រោង WEB ។

ដូច្នេះហេតុអ្វីបានជាមនុស្សជាច្រើនគិតថា REST នឹងសាមញ្ញជាង? គំនិតផ្ទាល់ខ្លួនរបស់ខ្ញុំគឺថាភាពសាមញ្ញជាក់ស្តែងនេះបានមកពី REST បង្ហាញខ្លួនឯង។ ទាំងនោះ។ REST មិនមែនជាពិធីការទេ ប៉ុន្តែជាគោលគំនិត... REST មិនមានស្តង់ដារទេ មានការណែនាំមួយចំនួន... REST មិនស្មុគស្មាញជាង HTTP ទេ។ សេរីភាពជាក់ស្តែង និងអនាធិបតេយ្យទាក់ទាញ "សិល្បករសេរី"។

ជាការពិតណាស់ REST មិនស្មុគស្មាញជាង HTTP ទេ។ ប៉ុន្តែ HTTP ខ្លួនវាគឺជាពិធីការដែលបានរចនាយ៉ាងល្អ ដែលបានបង្ហាញឱ្យឃើញពីតម្លៃរបស់វាអស់ជាច្រើនទសវត្សរ៍មកហើយ។ ប្រសិនបើមិនមានការយល់ដឹងស៊ីជម្រៅអំពី HTTP ខ្លួនវាទេនោះ REST មិនអាចត្រូវបានគេវិនិច្ឆ័យបានទេ។

ប៉ុន្តែអំពី RPC - អ្នកអាចធ្វើបាន។ វាគ្រប់គ្រាន់ហើយក្នុងការទទួលយកការបញ្ជាក់របស់វា។ ដូច្នេះតើអ្នកត្រូវការ JSON-RPC ឆោតល្ងង់? ឬវានៅតែពិបាក REST? អ្នកសម្រេចចិត្ត។

ខ្ញុំសង្ឃឹមដោយស្មោះថាខ្ញុំមិនខ្ជះខ្ជាយពេលវេលារបស់អ្នកទេ។

ប្រភព: www.habr.com