ക്ലയന്റ്-സെർവർ ആർക്കിടെക്ചർ എന്ന ആശയം എങ്ങനെ നിർവചിക്കപ്പെട്ടിരിക്കുന്നു എന്നത് പരിഗണിക്കാതെ തന്നെ (സാഹിത്യത്തിൽ അത്തരം നിരവധി നിർവചനങ്ങൾ ഉണ്ട്), ഈ ആശയത്തിന്റെ അടിസ്ഥാനം ഒരു വിതരണം ചെയ്ത കമ്പ്യൂട്ടിംഗ് മാതൃകയാണ്. ഏറ്റവും സാധാരണമായ സാഹചര്യത്തിൽ, താഴെ കക്ഷിഒപ്പം സെർവർരണ്ട് സംവേദന പ്രക്രിയകൾ മനസ്സിലാക്കുന്നു, അവയിലൊന്ന് മറ്റൊന്നിന് ചില സേവനങ്ങളുടെ ദാതാവാണ്.

"ക്ലയന്റ്-സെർവർ" എന്ന പദത്തിന്റെ അർത്ഥം "അഭ്യർത്ഥന-പ്രതികരണം" സ്കീമിന് അനുസൃതമായി അതിന്റെ പ്രവർത്തന ഭാഗങ്ങൾ സംവദിക്കുന്ന ഒരു സോഫ്റ്റ്വെയർ പാക്കേജിന്റെ ആർക്കിടെക്ചർ എന്നാണ്. ഈ സമുച്ചയത്തിന്റെ രണ്ട് സംവേദനാത്മക ഭാഗങ്ങൾ ഞങ്ങൾ പരിഗണിക്കുകയാണെങ്കിൽ, അവയിലൊന്ന് (ക്ലയന്റ്) ഒരു സജീവ പ്രവർത്തനം നിർവ്വഹിക്കുന്നു, അതായത്, അത് അഭ്യർത്ഥനകൾ ആരംഭിക്കുന്നു, മറ്റൊന്ന് (സെർവർ) അവയോട് നിഷ്ക്രിയമായി പ്രതികരിക്കുന്നു. സിസ്റ്റം വികസിക്കുമ്പോൾ, റോളുകൾ മാറിയേക്കാം, ഉദാഹരണത്തിന്, ചില സോഫ്‌റ്റ്‌വെയർ ബ്ലോക്ക് ഒരേസമയം ഒരു ബ്ലോക്കുമായി ബന്ധപ്പെട്ട് ഒരു സെർവറിന്റെയും മറ്റൊരു ബ്ലോക്കുമായി ബന്ധപ്പെട്ട് ഒരു ക്ലയന്റിന്റെയും പ്രവർത്തനങ്ങൾ നിർവഹിക്കും.

സെർവർ - ഒരൊറ്റ മെമ്മറി ഫീൽഡ് ഉള്ള ഒന്നോ അതിലധികമോ മൾട്ടി-യൂസർ പ്രോസസ്സറുകൾ, അത് ഉപയോക്താവിന്റെ ആവശ്യങ്ങൾക്ക് അനുസൃതമായി, കണക്കുകൂട്ടൽ, ആശയവിനിമയം, ഡാറ്റാബേസുകളിലേക്കുള്ള ആക്സസ് എന്നിവയുടെ പ്രവർത്തനങ്ങൾ നൽകുന്നു. സെർവർമറ്റ് പ്രോഗ്രാമുകൾക്ക് ചില സേവനങ്ങൾ നൽകുന്ന ഒരു പ്രോഗ്രാം എന്ന് വിളിക്കാം. അപ്പാച്ചെ വെബ് സെർവർ, ഡാറ്റാബേസ് സെർവറുകൾ - MySQL, ORACLE, നെറ്റ്‌വർക്ക് ഫയൽ സിസ്റ്റങ്ങൾ, വിൻഡോസ് പ്രിന്ററുകൾ എന്നിവയാണ് സെർവറുകളുടെ ഉദാഹരണങ്ങൾ.

ക്ലയന്റ് - ഒരു ഉപയോക്താവിനുള്ള ഒരു വർക്ക്സ്റ്റേഷൻ, രജിസ്ട്രേഷൻ മോഡും അവന്റെ ജോലിസ്ഥലത്ത് ആവശ്യമായ മറ്റ് ഫംഗ്ഷനുകളും നൽകുന്നു - കണക്കുകൂട്ടലുകൾ, ആശയവിനിമയം, ഡാറ്റാബേസുകളിലേക്കുള്ള ആക്സസ് മുതലായവ. സെർവർ പ്രോഗ്രാം നൽകുന്ന സേവനം ഉപയോഗിക്കുന്ന ഒരു പ്രോഗ്രാം എന്ന് വിളിക്കാം. ക്ലയന്റുകളുടെ ഉദാഹരണങ്ങൾ - MSIE (MS Internet Explorer), ICQ ക്ലയന്റ്.

മിക്കപ്പോഴും ആളുകൾ ഈ പ്രോഗ്രാമുകളിലൊന്ന് ഒരു ക്ലയന്റ് അല്ലെങ്കിൽ സെർവർ ആയി പ്രവർത്തിക്കുന്ന കമ്പ്യൂട്ടറിനെ പരാമർശിക്കുന്നു.

സാരാംശത്തിൽ, ക്ലയന്റും സെർവറും പ്രോഗ്രാമുകൾ നിർവഹിക്കുന്ന റോളുകളാണ്. ഉപഭോക്താക്കൾക്കും സെർവറുകൾക്കും ഒരേ കമ്പ്യൂട്ടറിൽ ശാരീരികമായി താമസിക്കാൻ കഴിയും. ഒരേ പ്രോഗ്രാം ഒരേ സമയം ഒരു ക്ലയന്റും സെർവറും ആകാം, മുതലായവ... ഇവ വെറും റോളുകളാണ്.

നമ്മൾ സമൂഹവുമായി ഒരു സാമ്യം വരച്ചാൽ - ഒരു ബാങ്ക് അല്ലെങ്കിൽ ഒരു സ്റ്റോർ - "സെർവറുകൾ". അവർ തങ്ങളുടെ ഉപഭോക്താക്കൾക്ക് ചില സേവനങ്ങൾ നൽകുന്നു. എന്നാൽ ബാങ്ക് അതേ സമയം മറ്റേതെങ്കിലും കമ്പനിയുടെ ക്ലയന്റായിരിക്കാം.

ക്ലയന്റ്-സെർവർ പ്രോസസ്സിംഗ് എന്നത് ഒരു ക്ലയന്റിനും സെർവറിനുമിടയിൽ ആപ്ലിക്കേഷൻ പ്രോസസ്സിംഗ് വിതരണം ചെയ്യുന്ന ഒരു അന്തരീക്ഷമാണ്. വിദൂര പ്ലാറ്റ്‌ഫോമുകൾ ആക്‌സസ് ചെയ്യുന്നതിനുള്ള ഒരു നിശ്ചിത സ്റ്റാൻഡേർഡ് എക്‌സ്‌ചേഞ്ച് പ്രോട്ടോക്കോളുകളും നടപടിക്രമങ്ങളും ഉപയോഗിച്ച് ക്ലയന്റും സെർവറും പരസ്പരം ആശയവിനിമയം നടത്തുന്നതിനൊപ്പം, പ്രോസസ്സിംഗിൽ പലപ്പോഴും വ്യത്യസ്ത തരം മെഷീനുകൾ ഉൾപ്പെടുന്നു.

പേഴ്‌സണൽ കമ്പ്യൂട്ടറുകളിൽ നിന്നുള്ള DBMS (ക്ലിപ്പർ, DBase, FoxPro, Paradox, Clarion പോലെയുള്ള നെറ്റ്‌വർക്ക് പതിപ്പുകൾ ഉണ്ട്, അത് PC-കൾക്കായി ഒരേ ഫോർമാറ്റിലുള്ള ഡാറ്റാബേസ് ഫയലുകൾ പങ്കിടുന്നു, അതേസമയം ടേബിളുകളിലേക്കും റെക്കോർഡുകളിലേക്കും ആക്‌സസ് പരിമിതപ്പെടുത്തുന്നതിന് നെറ്റ്‌വർക്ക് ലോക്കുകൾ നടപ്പിലാക്കുന്നു. എന്നിരുന്നാലും, എല്ലാ ജോലികളും നടക്കുന്നു. ഒരു പിസിയിൽ, വലിയ ശേഷിയുള്ള ഒരു പങ്കിട്ട റിമോട്ട് ഡിസ്കായിട്ടാണ് സെർവർ ഉപയോഗിക്കുന്നത്. ഈ പ്രവർത്തന രീതി ഹാർഡ്‌വെയർ തകരാറുകൾ മൂലം ഡാറ്റ നഷ്‌ടപ്പെടാനുള്ള സാധ്യതയിലേക്ക് നയിക്കുന്നു.

അത്തരം സിസ്റ്റങ്ങളുമായി താരതമ്യപ്പെടുത്തുമ്പോൾ, ക്ലയന്റ്-സെർവർ ആർക്കിടെക്ചറിൽ നിർമ്മിച്ച സിസ്റ്റങ്ങൾക്ക് ഇനിപ്പറയുന്ന ഗുണങ്ങളുണ്ട്:

ഒരു വർക്ക്സ്റ്റേഷനിൽ പ്രവർത്തിക്കുന്ന പ്രോഗ്രാമുകളുടെ വലിപ്പവും സങ്കീർണ്ണതയും വർദ്ധിപ്പിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്നു;


കൂടുതൽ കംപ്യൂട്ടിംഗ് ശക്തിയുള്ള ഒരു യന്ത്രമായ ഒരു സെർവറിലേക്ക് ഏറ്റവും അധ്വാനം-ഇന്റൻസീവ് പ്രവർത്തനങ്ങൾ കൈമാറുന്നത് ഉറപ്പാക്കുന്നു;


സെർവറിൽ ലഭ്യമായ ഇന്റേണൽ ഡാറ്റ പ്രൊട്ടക്ഷൻ മെക്കാനിസങ്ങൾ ഉപയോഗിച്ച് ഡാറ്റാബേസിൽ അടങ്ങിയിരിക്കുന്ന വിവരങ്ങൾ നഷ്‌ടപ്പെടാനുള്ള സാധ്യത കുറയ്ക്കുന്നു, ഉദാഹരണത്തിന്, ട്രാൻസാക്ഷൻ ട്രെയ്‌സിംഗ് സിസ്റ്റങ്ങൾ, പരാജയത്തിന് ശേഷമുള്ള റോൾബാക്ക്, ഡാറ്റയുടെ സമഗ്രത ഉറപ്പാക്കുന്നതിനുള്ള മാർഗ്ഗങ്ങൾ;


നെറ്റ്‌വർക്കിലൂടെ കൈമാറ്റം ചെയ്യപ്പെടുന്ന വിവരങ്ങളുടെ അളവ് നിരവധി തവണ കുറയ്ക്കുന്നു.


ഒരു ക്ലയന്റ്-സെർവർ ആർക്കിടെക്ചറിൽ, ഡാറ്റാബേസ് സെർവർ പങ്കിട്ട ഡാറ്റയിലേക്കുള്ള ആക്സസ് മാത്രമല്ല, ആ ഡാറ്റയുടെ എല്ലാ പ്രോസസ്സിംഗും കൈകാര്യം ചെയ്യുന്നു. SQL-ൽ രൂപപ്പെടുത്തിയ ഡാറ്റ വായിക്കാനോ മാറ്റാനോ ക്ലയന്റ് സെർവറിലേക്ക് അഭ്യർത്ഥനകൾ അയയ്ക്കുന്നു. ഡാറ്റയുടെ സമഗ്രതയും സ്ഥിരതയും നിരീക്ഷിക്കുമ്പോൾ സെർവർ തന്നെ ആവശ്യമായ എല്ലാ മാറ്റങ്ങളും തിരഞ്ഞെടുപ്പുകളും നടത്തുന്നു, കൂടാതെ ക്ലയന്റിന്റെ കമ്പ്യൂട്ടറിലേക്ക് ഒരു കൂട്ടം റെക്കോർഡുകളുടെ രൂപത്തിൽ അല്ലെങ്കിൽ ഒരു റിട്ടേൺ കോഡിന്റെ രൂപത്തിൽ ഫലങ്ങൾ അയയ്ക്കുന്നു.


ക്ലയന്റിനും സെർവറിനുമിടയിൽ കമ്പ്യൂട്ടിംഗ് ലോഡ് ഒപ്റ്റിമൽ ആയി വിതരണം ചെയ്യാൻ ഇത് നിങ്ങളെ അനുവദിക്കുന്നു, ഇത് സിസ്റ്റത്തിന്റെ പല സവിശേഷതകളെയും ബാധിക്കുന്നു: ചെലവ്, പ്രകടനം, പിന്തുണ.


1.2 കഥ…


വാസ്തുവിദ്യയും "ക്ലയന്റ്-സെർവർ" എന്ന പദവും ആദ്യമായി ഉപയോഗിച്ചത് 80-കളുടെ തുടക്കത്തിലാണ്. ക്ലയന്റ്-സെർവർ ആർക്കിടെക്ചറുള്ള ആദ്യ ആപ്ലിക്കേഷനുകൾ ഡാറ്റാബേസുകളായിരുന്നു.


ഇതിനുമുമ്പ്, വ്യക്തമായ വിഭജനം ഉണ്ടായിരുന്നില്ല - പ്രോഗ്രാം സാധാരണയായി എല്ലാം സ്വയം ചെയ്തു - ഫയൽ സിസ്റ്റത്തിലെ ഡാറ്റ ഉപയോഗിച്ച് പ്രവർത്തിക്കുക, ഉപയോക്താവിന് ഡാറ്റ അവതരിപ്പിക്കുക മുതലായവ. കാലക്രമേണ, ബിസിനസ്സിനായുള്ള ഡാറ്റയുടെ അളവും വിമർശനവും വർദ്ധിച്ചു, ഇത് കാലക്രമേണ. പ്രശ്നങ്ങൾ സൃഷ്ടിക്കാൻ തുടങ്ങി (പ്രകടനം, സുരക്ഷ, മറ്റുള്ളവ).


ശക്തമായ ഒരു പ്രത്യേക കമ്പ്യൂട്ടറിൽ (സെർവർ) ഡാറ്റാബേസ് ഇൻസ്റ്റാൾ ചെയ്യുന്നത് സൗകര്യപ്രദമാണെന്നും നെറ്റ്‌വർക്ക് വഴി ഒരു ചെറിയ കമ്പ്യൂട്ടറിന്റെ (ക്ലയന്റുകൾ) നിരവധി ഉപയോക്താക്കൾക്ക് ഈ ഡാറ്റാബേസ് ഉപയോഗിക്കാൻ അനുവദിക്കുമെന്നും അവർ തീരുമാനിച്ചു.


അടിസ്ഥാനപരമായി, ക്ലയന്റ്-സെർവർ സാങ്കേതികവിദ്യയുടെ ജനപ്രീതിയിൽ സ്ഫോടനം ഉണ്ടായത് റിലേഷണൽ ഡാറ്റാബേസുകൾക്കായുള്ള ലളിതമായ അന്വേഷണ ഭാഷയായ SQL-ന്റെ കണ്ടുപിടുത്തമാണ്. ഡാറ്റാബേസുകളിൽ പ്രവർത്തിക്കുന്നതിനുള്ള സാർവത്രിക മാനദണ്ഡമാണ് ഇന്ന് SQL. അടുത്തിടെ, ഈ "സ്ഫോടനം" ഇൻറർനെറ്റിന്റെ കണ്ടുപിടുത്തവുമായി തുടരുന്നു, അതിൽ അക്ഷരാർത്ഥത്തിൽ എല്ലാ ഇടപെടലുകളും ഒരു ക്ലയന്റ്-സെർവർ ആർക്കിടെക്ചർ ഉപയോഗിച്ചാണ് സംഭവിക്കുന്നത്.


1.3 പ്രോട്ടോക്കോളുകൾ


നെറ്റ്‌വർക്കിലെ സെർവറും ക്ലയന്റും പരസ്പരം "ഭാഷയിൽ" (വാക്കിന്റെ വിശാലമായ അർത്ഥത്തിൽ) "സംസാരിക്കുന്നു", അത് ഇരു കക്ഷികൾക്കും മനസ്സിലാക്കാവുന്നതേയുള്ളൂ. ഈ "ഭാഷയെ" ഒരു പ്രോട്ടോക്കോൾ എന്ന് വിളിക്കുന്നു.


ഒരു ബാങ്കിന്റെ കാര്യത്തിൽ, പ്രോട്ടോക്കോളിനെ ക്ലയന്റ് പൂരിപ്പിക്കുന്ന ഫോമുകൾ എന്ന് വിളിക്കാം.


ഞങ്ങളുടെ കാര്യത്തിൽ, പ്രോട്ടോക്കോളുകളുടെ ഉദാഹരണങ്ങൾ:


FTP (ഫയൽ ട്രാൻസ്ഫർ പ്രോട്ടോക്കോൾ)


HTTP (ഹൈപ്പർ ടെക്സ്റ്റ് ട്രാൻസ്ഫർ പ്രോട്ടോക്കോൾ)


SMTP (ലളിതമായ മെയിൽ ട്രാൻസ്ഫർ പ്രോട്ടോക്കോൾ)


IP (ഇന്റർനെറ്റ് പ്രോട്ടോക്കോൾ)


MySQL ക്ലയന്റ്/സെർവർ പ്രോട്ടോക്കോൾ


പ്രോട്ടോക്കോളുകൾ വ്യത്യസ്ത തലങ്ങളിൽ ആയിരിക്കാം എന്നത് ശ്രദ്ധിക്കുക. ലെവലുകളുടെ വർഗ്ഗീകരണ സംവിധാനങ്ങൾ വ്യത്യസ്തമായിരിക്കാം, എന്നാൽ ഏറ്റവും പ്രശസ്തമായ ലൈനുകളിൽ ഒന്നാണ് OSI (ഓപ്പൺ സിസ്റ്റംസ് ഇന്റർകണക്ഷൻ), അതിൽ 7 ലെവലുകൾ ഉണ്ട്.


ഉദാഹരണത്തിന്, HTTP ഒരു ആപ്ലിക്കേഷനാണ് (ഏഴാം - ഉയർന്നത്) ലെയർ പ്രോട്ടോക്കോൾ, കൂടാതെ IP ഒരു നെറ്റ്‌വർക്ക് (മൂന്നാം) ലെയർ പ്രോട്ടോക്കോൾ ആണ്.


1.4 ക്ലയന്റ്-സെർവർ ആർക്കിടെക്ചറിലെ പ്രവർത്തനങ്ങളുടെ വിതരണം


ഒരു ക്ലാസിക് ക്ലയന്റ്-സെർവർ ആർക്കിടെക്ചറിൽ, ആപ്ലിക്കേഷന്റെ മൂന്ന് പ്രധാന ഭാഗങ്ങൾ രണ്ട് ഫിസിക്കൽ മൊഡ്യൂളുകളിൽ വിതരണം ചെയ്യണം. സാധാരണഗതിയിൽ, ഡാറ്റ സ്റ്റോറേജ് സോഫ്‌റ്റ്‌വെയർ സെർവറിൽ സ്ഥിതി ചെയ്യുന്നു (ഉദാഹരണത്തിന്, ഒരു ഡാറ്റാബേസ് സെർവർ), ഉപയോക്തൃ ഇന്റർഫേസ് ക്ലയന്റ് വശത്താണ്, പക്ഷേ ഡാറ്റ പ്രോസസ്സിംഗ് ക്ലയന്റിനും സെർവർ ഭാഗങ്ങൾക്കും ഇടയിൽ വിതരണം ചെയ്യണം. രണ്ട്-ടയർ ആർക്കിടെക്ചറിന്റെ പ്രധാന പോരായ്മ ഇതാണ്, ഇത് ക്ലയന്റ്-സെർവർ സിസ്റ്റങ്ങളുടെ വികസനത്തെ വളരെയധികം സങ്കീർണ്ണമാക്കുന്ന നിരവധി അസുഖകരമായ സവിശേഷതകൾക്ക് കാരണമാകുന്നു.


അത്തരം സിസ്റ്റങ്ങളുടെ വികസന പ്രക്രിയ വളരെ സങ്കീർണ്ണമാണ്, കൂടാതെ ക്ലയന്റിനും സെർവർ ഭാഗങ്ങൾക്കും ഇടയിൽ ആപ്ലിക്കേഷന്റെ പ്രവർത്തനം എങ്ങനെ വിതരണം ചെയ്യണം എന്നതിന്റെ തീരുമാനമാണ് ഏറ്റവും പ്രധാനപ്പെട്ട ചുമതലകളിൽ ഒന്ന്. ഈ പ്രശ്നം പരിഹരിക്കാൻ ശ്രമിക്കുമ്പോൾ, ഡവലപ്പർമാർക്ക് ടു-ടയർ, ത്രീ-ടയർ, മൾട്ടി-ടയർ ആർക്കിടെക്ചറുകൾ ലഭിക്കും. ക്ലയന്റിനും സെർവറിനുമിടയിൽ എത്ര ഇന്റർമീഡിയറ്റ് ലിങ്കുകൾ ഉൾപ്പെടുത്തിയിട്ടുണ്ട് എന്നതിനെ ആശ്രയിച്ചിരിക്കുന്നു.


ക്ലയന്റ് ആപ്ലിക്കേഷൻ പരിഹരിക്കുന്ന പ്രധാന ദൗത്യം ഉപയോക്താവുമായി ഒരു ഇന്റർഫേസ് നൽകുന്നു, അതായത് ഡാറ്റ നൽകുക, ഉപയോക്തൃ-സൗഹൃദ രൂപത്തിൽ ഫലങ്ങൾ അവതരിപ്പിക്കുക, ആപ്ലിക്കേഷൻ സാഹചര്യങ്ങൾ കൈകാര്യം ചെയ്യുക.


ഡാറ്റയുടെ വിശ്വാസ്യത, സ്ഥിരത, സുരക്ഷ എന്നിവ ഉറപ്പുവരുത്തുക, ക്ലയന്റ് അഭ്യർത്ഥനകൾ കൈകാര്യം ചെയ്യുക, SQL അന്വേഷണങ്ങളുടെ വേഗത്തിലുള്ള പ്രോസസ്സിംഗ് എന്നിവയാണ് സെർവർ DBMS-ന്റെ പ്രധാന പ്രവർത്തനങ്ങൾ.


ആപ്ലിക്കേഷന്റെ മുഴുവൻ ലോജിക്കും - ആപ്ലിക്കേഷൻ ടാസ്ക്കുകൾ, ബിസിനസ്സ് നിയമങ്ങൾ - രണ്ട്-ടയർ ആർക്കിടെക്ചറിൽ ഡെവലപ്പർ രണ്ട് പ്രക്രിയകൾക്കിടയിൽ വിതരണം ചെയ്യുന്നു: ക്ലയന്റ്, സെർവർ (ചിത്രം 1).


ആദ്യം, ആപ്ലിക്കേഷന്റെ മിക്ക പ്രവർത്തനങ്ങളും ക്ലയന്റ് പരിഹരിച്ചു, സെർവർ SQL അന്വേഷണങ്ങൾ പ്രോസസ്സ് ചെയ്യുന്നതിൽ മാത്രമാണ് ഉൾപ്പെട്ടിരുന്നത്. ഈ വാസ്തുവിദ്യയെ "കട്ടിയുള്ള ക്ലയന്റ് - നേർത്ത സെർവർ" എന്ന് വിളിക്കുന്നു.


സെർവറിൽ സംഭരിച്ച നടപടിക്രമങ്ങൾ സൃഷ്ടിക്കുന്നതിനുള്ള കഴിവിന്റെ ഉദയം, അതായത് ആന്തരിക പ്രവർത്തന ലോജിക്കോടുകൂടിയ കംപൈൽ ചെയ്ത പ്രോഗ്രാമുകൾ, പ്രവർത്തനങ്ങളുടെ വർദ്ധിച്ചുവരുന്ന ഭാഗം സെർവറിലേക്ക് മാറ്റാനുള്ള പ്രവണതയിലേക്ക് നയിച്ചു. സെർവർ കൂടുതൽ കൂടുതൽ "കൊഴുപ്പ്" ആയിത്തീർന്നു, കൂടാതെ ക്ലയന്റ് "നേർത്തത്" ആയിത്തീർന്നു.


ഈ പരിഹാരത്തിന് വ്യക്തമായ ഗുണങ്ങളുണ്ട്, ഉദാഹരണത്തിന്, ഇത് പരിപാലിക്കാൻ എളുപ്പമാണ്, കാരണം എല്ലാ മാറ്റങ്ങളും ഒരിടത്ത് മാത്രം നടത്തേണ്ടതുണ്ട് - സെർവറിൽ.


മുകളിൽ ചർച്ച ചെയ്ത മോഡലുകൾക്ക് ഇനിപ്പറയുന്ന ദോഷങ്ങളുമുണ്ട്.


1. "കട്ടിയുള്ള" ക്ലയന്റ്:


- ഭരണത്തിന്റെ സങ്കീർണ്ണത;


- സോഫ്‌റ്റ്‌വെയർ അപ്‌ഡേറ്റ് ചെയ്യുന്നത് കൂടുതൽ സങ്കീർണ്ണമാകുന്നു, കാരണം ഇത് മുഴുവൻ സിസ്റ്റത്തിലും ഒരേസമയം മാറ്റിസ്ഥാപിക്കേണ്ടതുണ്ട്;


- അധികാരങ്ങളുടെ വിതരണം കൂടുതൽ സങ്കീർണ്ണമാകുന്നു, കാരണം ആക്സസ് പരിമിതപ്പെടുത്തിയിരിക്കുന്നത് പ്രവർത്തനങ്ങളല്ല, പട്ടികകളാൽ;


- പ്രോസസ്സ് ചെയ്യാത്ത ഡാറ്റ അതിലൂടെ കൈമാറുന്നതിനാൽ നെറ്റ്‌വർക്ക് ഓവർലോഡ് ചെയ്യുന്നു;


- ദുർബലമായ ഡാറ്റ പരിരക്ഷണം, കാരണം അധികാരങ്ങൾ ശരിയായി വിതരണം ചെയ്യുന്നത് ബുദ്ധിമുട്ടാണ്.


2. "ഫാറ്റ്" സെർവർ:


- PL/SQL പോലുള്ള ഭാഷകൾ അത്തരം സോഫ്റ്റ്‌വെയർ വികസിപ്പിക്കുന്നതിന് അനുയോജ്യമല്ലാത്തതിനാലും നല്ല ഡീബഗ്ഗിംഗ് ടൂളുകളില്ലാത്തതിനാലും നടപ്പിലാക്കൽ കൂടുതൽ സങ്കീർണ്ണമാകുന്നു;


- PL/SQL പോലുള്ള ഭാഷകളിൽ എഴുതിയ പ്രോഗ്രാമുകളുടെ പ്രകടനം മറ്റ് ഭാഷകളിൽ സൃഷ്ടിച്ചതിനേക്കാൾ വളരെ കുറവാണ്, ഇത് സങ്കീർണ്ണമായ സിസ്റ്റങ്ങൾക്ക് പ്രധാനമാണ്;


- DBMS ഭാഷകളിൽ എഴുതിയ പ്രോഗ്രാമുകൾ സാധാരണയായി വിശ്വസനീയമായി പ്രവർത്തിക്കില്ല; അവയിലെ ഒരു പിശക് മുഴുവൻ ഡാറ്റാബേസ് സെർവറിന്റെ പരാജയത്തിലേക്ക് നയിച്ചേക്കാം;


- തത്ഫലമായുണ്ടാകുന്ന പ്രോഗ്രാമുകൾ മറ്റ് സിസ്റ്റങ്ങളിലേക്കും പ്ലാറ്റ്ഫോമുകളിലേക്കും പൂർണ്ണമായും പോർട്ടബിൾ അല്ല.


ഈ പ്രശ്നങ്ങൾ പരിഹരിക്കുന്നതിന്, മൾട്ടി-ലെവൽ (മൂന്നോ അതിലധികമോ ലെവലുകൾ) ക്ലയന്റ്-സെർവർ ആർക്കിടെക്ചറുകൾ ഉപയോഗിക്കുന്നു. ഒരു മൾട്ടി-ലെവൽ ക്ലയന്റ്-സെർവർ ആർക്കിടെക്ചറിന് ഡിസ്ട്രിബ്യൂട്ടഡ് കമ്പ്യൂട്ടിംഗിനെ ഗണ്യമായി ലളിതമാക്കാൻ കഴിയും, ഇത് കൂടുതൽ വിശ്വസനീയം മാത്രമല്ല, കൂടുതൽ ആക്സസ് ചെയ്യാവുന്നതുമാണ്.


എന്നിരുന്നാലും, സംഭരിച്ച നടപടിക്രമങ്ങൾ എഴുതിയിരിക്കുന്ന ഭാഷ സങ്കീർണ്ണമായ ആപ്ലിക്കേഷൻ ലോജിക് എളുപ്പത്തിൽ നടപ്പിലാക്കാൻ കഴിയുന്നത്ര ശക്തമോ വഴക്കമുള്ളതോ അല്ല.


ആപ്ലിക്കേഷൻ ടാസ്‌ക്കുകളുടെയും ബിസിനസ്സ് നിയമങ്ങളുടെയും നിർവ്വഹണം ഒരു പ്രത്യേക ആപ്ലിക്കേഷൻ ഘടകത്തെ (അല്ലെങ്കിൽ നിരവധി ഘടകങ്ങൾ) ഏൽപ്പിക്കുന്ന പ്രവണത ഉണ്ടായിരുന്നു, അത് പ്രത്യേകമായി സമർപ്പിത കമ്പ്യൂട്ടറിൽ - ആപ്ലിക്കേഷൻ സെർവറിൽ അല്ലെങ്കിൽ ഡാറ്റാബേസ് സെർവർ പ്രവർത്തിക്കുന്ന അതേ കമ്പ്യൂട്ടറിൽ പ്രവർത്തിക്കാൻ കഴിയും. . ഇങ്ങനെയാണ് ത്രീ-ടയർ, മൾട്ടി-ടയർ ക്ലയന്റ്-സെർവർ ആർക്കിടെക്ചറുകൾ ഉടലെടുത്തത്.





അരി. 1. ക്ലയന്റും സെർവറും തമ്മിലുള്ള പ്രവർത്തനങ്ങളുടെ വിതരണം


അത്തരമൊരു മൾട്ടി-ഘടക ആപ്ലിക്കേഷന്റെ പല ഘടകങ്ങളുടെയും സംയുക്ത പ്രവർത്തനം ഉറപ്പാക്കുന്ന പ്രത്യേക മിഡിൽവെയർ ഉയർന്നുവന്നിട്ടുണ്ട്. അത്തരം ആപ്ലിക്കേഷനുകൾ വഴക്കമുള്ളതും അളക്കാവുന്നതും എന്നാൽ വികസിപ്പിക്കാൻ ബുദ്ധിമുട്ടുള്ളതുമാണ്.



ഗ്രന്ഥസൂചിക

1. ഇൻഫോർമാറ്റിക്സ് / എഡ്. എൻ.വി. മകരോവ - എം.: ഫിനാൻസ് ആൻഡ് സ്റ്റാറ്റിസ്റ്റിക്സ്, 1998.
   

   എവ്ഡോകിമോവ് വി.വി. മറ്റുള്ളവ. സാമ്പത്തിക ഇൻഫോർമാറ്റിക്സ്. സെന്റ് പീറ്റേഴ്സ്ബർഗ്: പീറ്റർ, 2004.
   

   കസാക്കോവ് എസ്.ഐ. നെറ്റ്‌വർക്ക് സാങ്കേതികവിദ്യകളുടെ അടിസ്ഥാനകാര്യങ്ങൾ - എം.: റേഡിയോ ആൻഡ് കമ്മ്യൂണിക്കേഷൻ, 2004.
   

   കൊഗലോവ്സ്കി എം.ആർ., പേഴ്സണൽ കമ്പ്യൂട്ടറുകളിലെ ഡാറ്റാബേസ് സാങ്കേതികവിദ്യ, - എം.: ഫിനാൻസ് ആൻഡ് സ്റ്റാറ്റിസ്റ്റിക്സ്, 2003.
   

   പോപോവ് വി.വി. കമ്പ്യൂട്ടർ സാങ്കേതികവിദ്യയുടെ അടിസ്ഥാനകാര്യങ്ങൾ. –എം.: ഫിനാൻസ് ആൻഡ് സ്റ്റാറ്റിസ്റ്റിക്സ്, 2001.
   

   ഫിഗർനോവ് വി.ഇ. ഉപയോക്താവിനുള്ള ഐബിഎം പി.സി. എം., 2000.
   

ഓപ്പറേറ്റിംഗ് സിസ്റ്റം MS-DOS. അടിസ്ഥാന ആശയങ്ങളും കമാൻഡുകളും അടിസ്ഥാന ആശയങ്ങൾ: ഡാറ്റാബേസ്, ഡിബിഎംഎസ്, എന്റിറ്റി, ആട്രിബ്യൂട്ട്, റിലേഷൻഷിപ്പ് (ഒന്ന്-ഒന്ന്, ഒന്നിൽ നിന്ന് പലതും, പലതും, പലതും), റിലേഷൻഷിപ്പ്, പ്രൈമറി കീ

ഫയൽ സെർവർ ആർക്കിടെക്ചർ

പരമ്പരാഗത ഇൻഫർമേഷൻ സിസ്റ്റം ആർക്കിടെക്ചറുകൾ.

വിവര സംവിധാനങ്ങളുടെ അടിസ്ഥാന പ്രവർത്തനങ്ങൾ.

ഇൻഫർമേഷൻ സിസ്റ്റം ആർക്കിടെക്ചർ- ഒരു വിവര സിസ്റ്റത്തിന്റെ ഘടകങ്ങളുടെ മാതൃക, ഘടന, നിർവ്വഹിച്ച പ്രവർത്തനങ്ങൾ, പരസ്പരബന്ധം എന്നിവ നിർവചിക്കുന്ന ഒരു ആശയം. (പദാവലി)

വീക്ഷണകോണിൽ നിന്ന് സോഫ്റ്റ്‌വെയർ, ഹാർഡ്‌വെയർ നടപ്പിലാക്കൽനിരവധി സാധാരണ ഐസി ആർക്കിടെക്ചറുകൾ വേർതിരിച്ചറിയാൻ കഴിയും.

ഒരു വിവര സിസ്റ്റത്തിന്റെ ഘടകങ്ങളെ അവ നിർവ്വഹിക്കുന്ന പ്രവർത്തനങ്ങൾ അനുസരിച്ച് മൂന്ന് ലെയറുകളായി തിരിക്കാം: ഒരു അവതരണ പാളി, ഒരു ബിസിനസ് ലോജിക് ലെയർ, ഒരു ഡാറ്റ ആക്സസ് ലെയർ.

അവതരണ പാളി- ഉപയോക്താവുമായുള്ള ആശയവിനിമയവുമായി ബന്ധപ്പെട്ട എല്ലാം: ബട്ടണുകൾ അമർത്തുക, മൗസ് ചലിപ്പിക്കുക, ഒരു ചിത്രം വരയ്ക്കുക, തിരയൽ ഫലങ്ങൾ പ്രദർശിപ്പിക്കുക തുടങ്ങിയവ.

ബിസിനസ്സ് യുക്തി- നിയമങ്ങൾ, ഉപയോക്തൃ പ്രവർത്തനങ്ങൾ അല്ലെങ്കിൽ ആന്തരിക ഇവന്റുകൾ എന്നിവയ്ക്കുള്ള ആപ്ലിക്കേഷന്റെ പ്രതികരണത്തിനുള്ള അൽഗോരിതങ്ങൾ, ഡാറ്റ പ്രോസസ്സിംഗ് നിയമങ്ങൾ.

ഡാറ്റ ആക്സസ് ലെയർ- ആപ്ലിക്കേഷൻ പരിഹരിക്കുന്ന ആപ്ലിക്കേഷൻ ടാസ്ക്കുമായി ബന്ധപ്പെട്ട ഡാറ്റയുടെ സംഭരണം, വീണ്ടെടുക്കൽ, പരിഷ്ക്കരണം, ഇല്ലാതാക്കൽ

പ്രാദേശിക നെറ്റ്‌വർക്കുകൾ പ്രത്യക്ഷപ്പെട്ടു. നെറ്റ്‌വർക്കിലൂടെ ഫയലുകൾ കൈമാറാൻ തുടങ്ങി. ആദ്യം പിയർ-ടു-പിയർ നെറ്റ്‌വർക്കുകൾ ഉണ്ടായിരുന്നു - എല്ലാ കമ്പ്യൂട്ടറുകൾക്കും തുല്യ അവകാശങ്ങളുണ്ട്. 3

എല്ലാവർക്കുമായി ആക്സസ് ചെയ്യാവുന്ന എല്ലാ ഫയലുകളും നെറ്റ്‌വർക്കിലെ ഒരു സമർപ്പിത കമ്പ്യൂട്ടറിൽ - ഒരു ഫയൽ സെർവറിൽ സംഭരിക്കുക എന്ന ആശയം ഉടലെടുത്തു.

പ്രാദേശിക ആപ്ലിക്കേഷനുകൾക്ക് സമാനമായ ഘടനയുള്ളതും പ്രോഗ്രാമുകളും ഡാറ്റയും സംഭരിക്കുന്നതിന് നെറ്റ്‌വർക്ക് റിസോഴ്‌സ് ഉപയോഗിക്കുന്നതുമായ ആപ്ലിക്കേഷനുകളാണ് ഫയൽ സെർവർ ആപ്ലിക്കേഷനുകൾ. സെർവർ പ്രവർത്തനങ്ങൾ: ഡാറ്റയും പ്രോഗ്രാം കോഡും സംഭരിക്കുന്നു. ക്ലയന്റ് ഫംഗ്‌ഷനുകൾ: ഡാറ്റ പ്രോസസ്സിംഗ് ക്ലയന്റ് വശത്ത് മാത്രമായി സംഭവിക്കുന്നു.

ഇടപാടുകാരുടെ എണ്ണം പത്തിൽ പരിമിതപ്പെടുത്തിയിരിക്കുന്നു.

1. ഡാറ്റയുമായി പ്രവർത്തിക്കുന്നതിനുള്ള മൾട്ടി-യൂസർ മോഡ്;

2. കേന്ദ്രീകൃത പ്രവേശന നിയന്ത്രണത്തിന്റെ സൗകര്യം;

3. കുറഞ്ഞ വികസന ചെലവ്;

1. കുറഞ്ഞ പ്രകടനം;

2. കുറഞ്ഞ വിശ്വാസ്യത;

3. ദുർബലമായ വിപുലീകരണ കഴിവുകൾ;

ഒരു ഫയൽ സെർവർ ആർക്കിടെക്ചറിന്റെ പോരായ്മകൾ വ്യക്തമാണ്, പ്രധാനമായും ഡാറ്റ ഒരിടത്ത് സംഭരിക്കുകയും മറ്റൊരിടത്ത് പ്രോസസ്സ് ചെയ്യുകയും ചെയ്യുന്നു എന്ന വസ്തുതയിൽ നിന്നാണ്. ഇതിനർത്ഥം അവ നെറ്റ്‌വർക്കിലൂടെ കൈമാറ്റം ചെയ്യപ്പെടണം, ഇത് വളരെ ഉയർന്ന നെറ്റ്‌വർക്ക് ലോഡുകൾക്ക് കാരണമാകുന്നു, അതിന്റെ ഫലമായി, ഒരേസമയം ക്ലയന്റുകളുടെ എണ്ണം വർദ്ധിക്കുന്നതിനനുസരിച്ച് ആപ്ലിക്കേഷൻ പ്രകടനത്തിൽ കുത്തനെ കുറയുന്നു. ഈ വാസ്തുവിദ്യയുടെ രണ്ടാമത്തെ പ്രധാന പോരായ്മ, ഡാറ്റയുടെ സമഗ്രതയുടെയും സ്ഥിരതയുടെയും പ്രശ്നങ്ങൾക്കുള്ള വികേന്ദ്രീകൃത പരിഹാരമാണ്, ഡാറ്റയിലേക്കുള്ള ഒരേസമയം ആക്സസ്. ഈ പരിഹാരം ആപ്ലിക്കേഷന്റെ വിശ്വാസ്യത കുറയ്ക്കുന്നു.

ഒരു ക്ലയന്റ്-സെർവർ ആർക്കിടെക്ചറും ഫയൽ-സെർവർ ആർക്കിടെക്ചറും തമ്മിലുള്ള പ്രധാന വ്യത്യാസം ആന്തരിക ഡാറ്റ പ്രാതിനിധ്യത്തിൽ നിന്നുള്ള സംഗ്രഹമാണ് (ഫിസിക്കൽ ഡാറ്റ സ്കീമ). ക്ലയന്റ് പ്രോഗ്രാമുകൾ ഇപ്പോൾ ലോജിക്കൽ സർക്യൂട്ട് തലത്തിൽ ഡാറ്റ കൈകാര്യം ചെയ്യുന്നു.

അതിനാൽ, ക്ലയന്റ്-സെർവർ ആർക്കിടെക്ചറിന്റെ ഉപയോഗം, ഡാറ്റാബേസ് സെർവറിന്റെ ഹാർഡ്‌വെയർ (പലപ്പോഴും സോഫ്‌റ്റ്‌വെയർ) ഭാഗങ്ങളിൽ നിന്ന് സ്വതന്ത്രമായി ഒരു കേന്ദ്രീകൃത ഡാറ്റാബേസ് ഉപയോഗിച്ച് വിശ്വസനീയമായ (ഡാറ്റ ഇന്റഗ്രിറ്റിയുടെ കാര്യത്തിൽ) മൾട്ടി-യൂസർ ഇൻഫർമേഷൻ സിസ്റ്റങ്ങൾ സൃഷ്ടിക്കുന്നത് സാധ്യമാക്കി. ഉപയോക്തൃ ഇന്റർഫേസ് (GUI) ഒരു പ്രാദേശിക നെറ്റ്‌വർക്ക് വഴി ബന്ധിപ്പിച്ചിരിക്കുന്ന ക്ലയന്റ് സ്റ്റേഷനുകളിൽ. കൂടാതെ, ആപ്ലിക്കേഷൻ വികസന ചെലവ് ഗണ്യമായി കുറഞ്ഞു.

പ്രധാന സവിശേഷതകൾ: 5

 സെർവർ സോഫ്‌റ്റ്‌വെയറിലേക്കുള്ള അഭ്യർത്ഥനകളിലൂടെ ക്ലയന്റ് പ്രോഗ്രാം ഡാറ്റയുമായി പ്രവർത്തിക്കുന്നു.

 ആപ്ലിക്കേഷന്റെ അടിസ്ഥാന പ്രവർത്തനങ്ങൾ ക്ലയന്റിനും സെർവറിനും ഇടയിൽ വിഭജിച്ചിരിക്കുന്നു.

 മൾട്ടി-യൂസർ വർക്കിനുള്ള പൂർണ്ണ പിന്തുണ

 ഡാറ്റ സമഗ്രത ഗ്യാരണ്ടി

 ആപ്ലിക്കേഷനുകളുടെ ബിസിനസ് ലോജിക് ക്ലയന്റ് സോഫ്‌റ്റ്‌വെയറിൽ തുടർന്നു. അൽഗോരിതങ്ങളിൽ എന്തെങ്കിലും മാറ്റം വരുത്തുമ്പോൾ, ഓരോ ക്ലയന്റിലും നിങ്ങൾ ഉപയോക്തൃ സോഫ്റ്റ്‌വെയർ അപ്‌ഡേറ്റ് ചെയ്യേണ്ടതുണ്ട്.

 സെർവറുമായുള്ള ആശയവിനിമയ ചാനലുകളുടെ ബാൻഡ്‌വിഡ്‌ത്തിന് ഉയർന്ന ആവശ്യകതകൾ, ഇത് ഒരു പ്രാദേശിക നെറ്റ്‌വർക്കിൽ ഒഴികെയുള്ള ക്ലയന്റ് സ്റ്റേഷനുകളുടെ ഉപയോഗം തടയുന്നു.

 ഹാക്കിംഗിൽ നിന്നുള്ള ദുർബലമായ ഡാറ്റ സംരക്ഷണം, പ്രത്യേകിച്ച് സത്യസന്ധമല്ലാത്ത സിസ്റ്റം ഉപയോക്താക്കളിൽ നിന്ന്.

 സിസ്റ്റത്തിന്റെ ഉപയോക്തൃ വർക്ക്സ്റ്റേഷനുകളുടെ അഡ്മിനിസ്ട്രേഷന്റെയും കോൺഫിഗറേഷന്റെയും ഉയർന്ന സങ്കീർണ്ണത.

 ക്ലയന്റ് സൈറ്റുകളിൽ ശക്തമായ പിസികൾ ഉപയോഗിക്കേണ്ടതിന്റെ ആവശ്യകത.

 ബിസിനസ് ലോജിക് എക്സിക്യൂട്ട് ചെയ്യുന്നതിനും ഒരു പ്രോഗ്രാമിൽ ഉപയോക്തൃ ഇന്റർഫേസ് നൽകുന്നതിനുമുള്ള നിർണായക പ്രാധാന്യം കാരണം സിസ്റ്റം വികസനത്തിന്റെ ഉയർന്ന സങ്കീർണ്ണത.

ക്ലാസിക്കൽ അല്ലെങ്കിൽ 2-ലെയർ ക്ലയന്റ്-സെർവർ ആർക്കിടെക്ചറിന്റെ പോരായ്മകളിൽ ഭൂരിഭാഗവും IS ബിസിനസ് ലോജിക്കിന്റെ എക്സിക്യൂട്ടീവായി ക്ലയന്റ് സ്റ്റേഷന്റെ ഉപയോഗത്തിൽ നിന്നാണെന്ന് കാണാൻ എളുപ്പമാണ്. ഇക്കാരണത്താൽ, IS ആർക്കിടെക്ചറുകളുടെ കൂടുതൽ പരിണാമത്തിലെ ഒരു വ്യക്തമായ ഘട്ടം ഒരു "നേർത്ത ക്ലയന്റ്" എന്ന ആശയമായിരുന്നു, അതായത്, ഡാറ്റ പ്രോസസ്സിംഗ് അൽഗോരിതങ്ങളെ ബിസിനസ് ഫംഗ്ഷനുകളുടെ പ്രകടനവുമായി ബന്ധപ്പെട്ട ഭാഗങ്ങളായി വിഭജിക്കുന്നതും ഒരു മനുഷ്യനിൽ വിവരങ്ങൾ പ്രദർശിപ്പിക്കുന്നതുമായി ബന്ധപ്പെട്ടതുമാണ്. -സൗഹൃദ അവതരണം. അതേ സമയം, ക്ലയന്റ് മെഷീനിൽ രണ്ടാം ഭാഗം മാത്രമേ അവശേഷിക്കുന്നുള്ളൂ, പ്രാഥമിക പരിശോധനയും വിവരങ്ങളുടെ പ്രദർശനവുമായി ബന്ധപ്പെട്ടിരിക്കുന്നു, സിസ്റ്റത്തിന്റെ എല്ലാ യഥാർത്ഥ പ്രവർത്തനങ്ങളും സെർവർ ഭാഗത്തേക്ക് മാറ്റുന്നു.

ത്രീ-ലെയർ ആർക്കിടെക്ചറിലേക്കുള്ള ട്രാൻസിഷണൽ (2.5 ലെയറുകൾ)

സംഭരിച്ച നടപടിക്രമങ്ങളും സെർവർ-സൈഡ് ഡാറ്റ കണക്കുകൂട്ടലും ഉപയോഗിക്കുന്നത് ട്രാഫിക് കുറയ്ക്കുകയും സുരക്ഷ വർദ്ധിപ്പിക്കുകയും ചെയ്യുന്നു. ക്ലയന്റ് ഇപ്പോഴും ബിസിനസ്സ് ലോജിക്കിന്റെ ഒരു ഭാഗം നടപ്പിലാക്കുന്നു.

നിങ്ങൾക്ക് കാണാനാകുന്നതുപോലെ, സിസ്റ്റത്തിന്റെ ഈ ഓർഗനൈസേഷൻ ആദ്യത്തെ ഏകീകൃത സിസ്റ്റങ്ങളുടെ ഓർഗനൈസേഷനെ വളരെ അനുസ്മരിപ്പിക്കുന്നു, ഉപയോക്താവിന്റെ സ്ഥലം ഒരു ടെർമിനൽ അല്ല (കുപ്രസിദ്ധമായ ഗ്രീൻ സ്ക്രീൻ ഉള്ളത്), എന്നാൽ ഒരു ജിയുഐ നൽകുന്ന ഒരു വ്യക്തിഗത കമ്പ്യൂട്ടർ, ഉദാഹരണത്തിന്, അടുത്തിടെ ക്ലയന്റ് പ്രോഗ്രാമുകളായി സാധാരണ www ബ്രൗസറുകൾ ഉപയോഗിക്കാറുണ്ട്. തീർച്ചയായും, ഏതാണ്ട് ഏകീകൃത സംവിധാനങ്ങളിലേക്കുള്ള അത്തരമൊരു തിരിച്ചുവരവ് മറ്റൊരു സാങ്കേതിക തലത്തിലാണ് സംഭവിച്ചത്. DBMS-ന്റെ എല്ലാ ഗുണങ്ങളോടും കൂടിയ ഉപയോഗം നിർബന്ധിതമായി. ഡാറ്റാബേസ് സെർവറിന്റെ സംഭരിച്ച നടപടിക്രമങ്ങളുടെ സംവിധാനം ഉപയോഗിച്ച് സെർവർ സൈഡിനുള്ള പ്രോഗ്രാമുകൾ പ്രധാനമായും പ്രത്യേക ഭാഷകളിലാണ് എഴുതുന്നത്. എന്നിരുന്നാലും, ലോജിക്കൽ ഓർഗനൈസേഷന്റെ തലത്തിൽ, ഒരു നേർത്ത ക്ലയന്റുള്ള ക്ലയന്റ്-സെർവർ ആർക്കിടെക്ചറിലെ IS മൂന്ന് ലെയറുകളായി തിരിച്ചിരിക്കുന്നു - ഒരു ഡാറ്റ ലെയർ, ബിസിനസ് ഫംഗ്‌ഷനുകളുടെ ഒരു പാളി (സംഭരിച്ച നടപടിക്രമങ്ങൾ), ഒരു അവതരണ പാളി. നിർഭാഗ്യവശാൽ, സാധാരണയായി, അത്തരമൊരു ഐഎസ് ഡിസൈൻ സ്കീമിൽ, ഈ ആവശ്യത്തിനായി ഉദ്ദേശിക്കാത്ത ബിൽറ്റ്-ഇൻ ഡിബിഎംഎസ് ഭാഷകളിൽ ആപ്ലിക്കേഷന്റെ എല്ലാ ബിസിനസ്സ് ലോജിക്കും എഴുതാൻ കഴിയില്ല. ഇക്കാരണത്താൽ, മിക്കപ്പോഴും ബിസിനസ്സ് ഫംഗ്‌ഷനുകളുടെ ഒരു ഭാഗം സിസ്റ്റങ്ങളുടെ ക്ലയന്റ് ഭാഗത്ത് നടപ്പിലാക്കുന്നു, അതിന്റെ ഫലമായി അനിവാര്യമായും “തടിച്ചിരിക്കുന്നു”. ഭാഗികമായി ഇക്കാരണത്താൽ, ഭാഗികമായി അത്തരം ഐസികൾ രണ്ട് ഘടകങ്ങൾ ഉൾക്കൊള്ളുന്നതിനാൽ, ഈ ആർക്കിടെക്ചറിനെ പലപ്പോഴും 2.5-ലെയർ ക്ലയന്റ്-സെർവർ ആർക്കിടെക്ചർ എന്ന് വിളിക്കുന്നു.

2-ലെയർ ആർക്കിടെക്ചറിൽ നിന്ന് വ്യത്യസ്തമായി, 2.5-ലെയർ ആർക്കിടെക്ചറിന് സാധാരണയായി സിസ്റ്റത്തിന്റെ ക്ലയന്റിനും സെർവർ ഭാഗങ്ങൾക്കുമിടയിൽ അതിവേഗ ആശയവിനിമയ ചാനലുകൾ ആവശ്യമില്ല, കാരണം റെഡിമെയ്ഡ് കണക്കുകൂട്ടൽ ഫലങ്ങൾ നെറ്റ്‌വർക്കിലൂടെ കൈമാറുന്നു - മിക്കവാറും എല്ലാ കണക്കുകൂട്ടലുകളും സെർവർ വശത്താണ് നടത്തുന്നത്. . വിവര പരിരക്ഷയും ഗണ്യമായി മെച്ചപ്പെടുത്തിയിട്ടുണ്ട് - ഉപയോക്താക്കൾക്ക് സിസ്റ്റത്തിന്റെ പ്രവർത്തനങ്ങൾ ആക്സസ് ചെയ്യാനുള്ള അവകാശങ്ങൾ നൽകിയിരിക്കുന്നു, മാത്രമല്ല അതിന്റെ ഡാറ്റ ആക്സസ് ചെയ്യാതിരിക്കാനും. അതേ സമയം, ഏകീകൃത സമീപനത്തിന്റെ ഗുണങ്ങളോടൊപ്പം, ആർക്കിടെക്ചർ 2.5 അതിന്റെ എല്ലാ ദോഷങ്ങളും സ്വീകരിക്കുന്നു: പരിമിതമായ സ്കേലബിളിറ്റി, സോഫ്‌റ്റ്‌വെയർ പ്ലാറ്റ്‌ഫോമിനെ ആശ്രയിക്കൽ, നെറ്റ്‌വർക്ക് കമ്പ്യൂട്ടിംഗ് ഉറവിടങ്ങളുടെ പരിമിതമായ ഉപയോഗം. കൂടാതെ, സിസ്റ്റത്തിന്റെ സെർവർ ഭാഗത്തിനുള്ള പ്രോഗ്രാമുകൾ DBMS-ൽ നിർമ്മിച്ച സംഭരിച്ച നടപടിക്രമ ഭാഷകളിൽ എഴുതിയിരിക്കുന്നു, ഡാറ്റ മൂല്യനിർണ്ണയത്തിനും ലളിതമായ റിപ്പോർട്ടുകൾ നിർമ്മിക്കുന്നതിനും ഉദ്ദേശിച്ചുള്ളതാണ്, അല്ലാതെ എന്റർപ്രൈസ് സ്കെയിൽ IS എഴുതാൻ വേണ്ടിയല്ല. ഇതെല്ലാം സിസ്റ്റത്തിന്റെ പ്രകടനം കുറയ്ക്കുന്നു, ഐസി സൃഷ്ടിക്കുന്നതിനും പരിഷ്ക്കരിക്കുന്നതിനുമുള്ള സങ്കീർണ്ണത വർദ്ധിപ്പിക്കുന്നു, കൂടാതെ അതിന്റെ പ്രവർത്തനത്തിന് ആവശ്യമായ ഹാർഡ്വെയറിന്റെ വിലയിൽ ഏറ്റവും പ്രതികൂലമായ സ്വാധീനം ചെലുത്തുന്നു.

നോവിയോയിലെ വെബ് ഡെവലപ്പർ വ്‌ളാഡിമിർ പറയുന്നു:

വെബ്‌സൈറ്റുകൾ, വെബ് സേവനങ്ങൾ, മൊബൈൽ ആപ്ലിക്കേഷനുകൾ എന്നിവയുടെ മിക്ക ഡെവലപ്പർമാരും താമസിയാതെ അല്ലെങ്കിൽ പിന്നീട് ക്ലയന്റ്-സെർവർ ആർക്കിടെക്ചർ കൈകാര്യം ചെയ്യേണ്ടതുണ്ട്, അതായത്, ഒരു വെബ് API വികസിപ്പിക്കുകയോ അതുമായി സംയോജിപ്പിക്കുകയോ ചെയ്യുക. ഓരോ തവണയും പുതിയ എന്തെങ്കിലും കണ്ടുപിടിക്കാതിരിക്കാൻ, സമാനമായ സിസ്റ്റങ്ങൾ വികസിപ്പിക്കുന്നതിന്റെ അനുഭവത്തെ അടിസ്ഥാനമാക്കി, വെബ് API രൂപകൽപ്പനയ്ക്ക് താരതമ്യേന സാർവത്രിക സമീപനം വികസിപ്പിക്കേണ്ടത് പ്രധാനമാണ്. ഈ വിഷയത്തിനായി നീക്കിവച്ചിരിക്കുന്ന ഒരു സംയോജിത ലേഖന പരമ്പര ഞങ്ങൾ നിങ്ങളുടെ ശ്രദ്ധയിൽപ്പെടുത്തുന്നു.

ഏകദേശം ഒന്ന്: കഥാപാത്രങ്ങൾ

ഒരു ഘട്ടത്തിൽ, മറ്റൊരു വെബ് സേവനം സൃഷ്ടിക്കുന്ന പ്രക്രിയയിൽ, ക്ലയന്റ് ആപ്ലിക്കേഷനുകളുടെ ആവശ്യങ്ങൾ നിറവേറ്റുന്നതിനായി ഒരു വെബ് API രൂപകൽപന ചെയ്യുന്ന വിഷയത്തെക്കുറിച്ചുള്ള എന്റെ എല്ലാ അറിവും ചിന്തകളും ശേഖരിക്കാനും ഒരു ലേഖനത്തിന്റെ രൂപത്തിലോ ഒരു പരമ്പരയിലോ നൽകാനും ഞാൻ തീരുമാനിച്ചു. ലേഖനങ്ങൾ. തീർച്ചയായും, എന്റെ അനുഭവം കേവലമല്ല, സൃഷ്ടിപരമായ വിമർശനങ്ങളും കൂട്ടിച്ചേർക്കലുകളും സ്വാഗതാർഹമാണ്.

വായന സാങ്കേതികത്തേക്കാൾ കൂടുതൽ ദാർശനികമായി മാറി, പക്ഷേ സാങ്കേതിക ഭാഗത്തിന്റെ ആരാധകർക്ക് ചിന്തിക്കാൻ എന്തെങ്കിലും ഉണ്ടാകും. ഈ ലേഖനത്തിൽ അടിസ്ഥാനപരമായി പുതിയ എന്തെങ്കിലും, നിങ്ങൾ ഒരിക്കലും കേട്ടിട്ടില്ലാത്ത, വായിക്കാത്ത, നിങ്ങളെക്കുറിച്ച് ചിന്തിക്കാത്ത എന്തെങ്കിലും ഞാൻ പറയുമെന്ന് എനിക്ക് സംശയമുണ്ട്. എല്ലാം ഒരൊറ്റ സിസ്റ്റത്തിൽ ഉൾപ്പെടുത്താൻ ഞാൻ ശ്രമിക്കും, പ്രാഥമികമായി എന്റെ സ്വന്തം തലയിൽ, ഇത് ഇതിനകം വളരെയധികം വിലമതിക്കുന്നു. എന്നിരുന്നാലും, നിങ്ങളുടെ പരിശീലനത്തിൽ എന്റെ ചിന്തകൾ നിങ്ങൾക്ക് ഉപയോഗപ്രദമാകുമെങ്കിൽ ഞാൻ സന്തോഷിക്കും. അതിനാൽ, നമുക്ക് പോകാം.

ക്ലയന്റും സെർവറും

സെർവർഈ സാഹചര്യത്തിൽ, ഒരു HTTP അഭ്യർത്ഥന സ്വീകരിക്കാനും അത് പ്രോസസ്സ് ചെയ്യാനും ശരിയായ പ്രതികരണം നൽകാനും കഴിവുള്ള നെറ്റ്‌വർക്കിലെ ഒരു അമൂർത്ത മെഷീൻ ഞങ്ങൾ പരിഗണിക്കുന്നു. ഈ ലേഖനത്തിന്റെ പശ്ചാത്തലത്തിൽ, അതിന്റെ ഭൗതിക സത്തയും ആന്തരിക വാസ്തുവിദ്യയും തികച്ചും അപ്രധാനമാണ്, അത് ഒരു വിദ്യാർത്ഥി ലാപ്‌ടോപ്പോ ലോകമെമ്പാടുമുള്ള വ്യാവസായിക സെർവറുകളുടെ ഒരു വലിയ ക്ലസ്റ്ററോ ആകട്ടെ. അതുപോലെ, ഹുഡിന് കീഴിലുള്ളത് എന്താണെന്നത് ഞങ്ങൾക്ക് പ്രശ്നമല്ല, ആരാണ് വാതിൽക്കൽ അഭ്യർത്ഥനയെ അഭിവാദ്യം ചെയ്യുന്നത്, Apache അല്ലെങ്കിൽ Nginx, ഏത് അജ്ഞാത മൃഗം, PHP, Python അല്ലെങ്കിൽ Ruby അത് പ്രോസസ്സ് ചെയ്യുകയും പ്രതികരണം സൃഷ്ടിക്കുകയും ചെയ്യുന്നു, എന്ത് ഡാറ്റ സംഭരണം ഉപയോഗിക്കുന്നു : Postgresql, MySQL അല്ലെങ്കിൽ MongoDB . പ്രധാന കാര്യം സെർവർ പ്രധാന നിയമം പാലിക്കുന്നു എന്നതാണ് - കേൾക്കാനും മനസ്സിലാക്കാനും ക്ഷമിക്കാനും.

കക്ഷിഒരു HTTP അഭ്യർത്ഥന സൃഷ്ടിക്കാനും അയയ്ക്കാനും കഴിവുള്ള എന്തും ആകാം. ഈ ലേഖനത്തിലെ ഒരു നിശ്ചിത പോയിന്റ് വരെ, ഈ അഭ്യർത്ഥന അയയ്‌ക്കുമ്പോൾ ക്ലയന്റ് തനിക്കായി സജ്ജീകരിക്കുന്ന ലക്ഷ്യങ്ങളിലോ പ്രതികരണവുമായി അവൻ എന്തുചെയ്യുമെന്നോ ഞങ്ങൾക്ക് പ്രത്യേക താൽപ്പര്യമില്ല. ക്ലയന്റ് ബ്രൗസറിൽ പ്രവർത്തിക്കുന്ന ഒരു JavaScript സ്‌ക്രിപ്‌റ്റോ, ഒരു മൊബൈൽ ആപ്ലിക്കേഷനോ, സെർവറിൽ പ്രവർത്തിക്കുന്ന ഒരു ദുഷ്ട (അല്ലെങ്കിൽ അത്ര മോശമല്ലാത്ത) ഭൂതമോ, അല്ലെങ്കിൽ വളരെ ബുദ്ധിയുള്ള ഒരു റഫ്രിജറേറ്ററോ ആകാം (അങ്ങനെയുള്ളവ ഇതിനകം തന്നെ ഉണ്ട്).

മിക്കവാറും, മേൽപ്പറഞ്ഞ രണ്ടുപേരും തമ്മിലുള്ള ആശയവിനിമയ രീതിയെക്കുറിച്ച് ഞങ്ങൾ സംസാരിക്കും, അവർ പരസ്പരം മനസ്സിലാക്കുന്ന തരത്തിൽ, ഇരുവർക്കും ചോദ്യങ്ങളൊന്നുമില്ല.

REST ഫിലോസഫി

നേരിട്ടുള്ള നെറ്റ്‌വർക്ക് സ്റ്റോറേജ് (സെർവർ): ഡാറ്റ വീണ്ടെടുക്കൽ (GET), സേവിംഗ് (POST), പരിഷ്‌ക്കരണം (PUT/PATCH) ഡാറ്റ മാനേജ്‌മെന്റിനുള്ള ലളിതവും വ്യക്തമല്ലാത്തതുമായ ഇന്റർഫേസായിട്ടാണ് REST (പ്രാതിനിധ്യ സംസ്ഥാന കൈമാറ്റം) ആദ്യം വിഭാവനം ചെയ്തത്. ) കൂടാതെ ഇല്ലാതാക്കൽ (ഇല്ലാതാക്കുക). തീർച്ചയായും, അഭ്യർത്ഥനയിലെ പിശകുകൾ കൈകാര്യം ചെയ്യുക (അഭ്യർത്ഥന ശരിയായി സമാഹരിച്ചതാണോ), ഡാറ്റയിലേക്കുള്ള ആക്‌സസ് നിയന്ത്രിക്കുക (പെട്ടെന്ന് നിങ്ങൾ ഇത് അറിയരുത്), ഇൻകമിംഗ് ഡാറ്റ സാധൂകരിക്കുക (പെട്ടെന്ന് നിങ്ങൾ അസംബന്ധം എഴുതി) തുടങ്ങിയ ഓപ്‌ഷനുകൾ ഈ ലിസ്‌റ്റിൽ എപ്പോഴും ഉണ്ടായിരിക്കും. പൊതുവായ, സാധ്യമായ എല്ലാ പരിശോധനകളും , ആഗ്രഹം നിറവേറ്റുന്നതിന് മുമ്പ് സെർവർ നടപ്പിലാക്കുന്നു കക്ഷി.

കൂടാതെ, REST ന് നിരവധി വാസ്തുവിദ്യാ തത്വങ്ങളുണ്ട്, അവയുടെ ഒരു ലിസ്റ്റ് REST നെക്കുറിച്ചുള്ള മറ്റേതൊരു ലേഖനത്തിലും കാണാം. നമുക്ക് അവയെ ഹ്രസ്വമായി പരിശോധിക്കാം, അങ്ങനെ അവ കൈയിലുണ്ട്, നിങ്ങൾ എവിടെയും പോകേണ്ടതില്ല:

ക്ലയന്റിൽനിന്നുള്ള സെർവറിന്റെ സ്വാതന്ത്ര്യം- സെർവറുകളും ക്ലയന്റുകളും പരസ്പരം സ്വതന്ത്രമായി മറ്റുള്ളവർക്ക് തൽക്ഷണം മാറ്റിസ്ഥാപിക്കാൻ കഴിയും, കാരണം അവയ്ക്കിടയിലുള്ള ഇന്റർഫേസ് മാറില്ല. സെർവർ ക്ലയന്റ് അവസ്ഥകൾ സംഭരിക്കുന്നില്ല.
വിഭവ വിലാസങ്ങളുടെ പ്രത്യേകത- ഡാറ്റയുടെ ഓരോ യൂണിറ്റിനും (ഏത് അളവിലുള്ള നെസ്റ്റിംഗിലും) അതിന്റേതായ തനതായ URL ഉണ്ട്, വാസ്തവത്തിൽ ഇത് പൂർണ്ണമായും ഒരു അദ്വിതീയ റിസോഴ്സ് ഐഡന്റിഫയർ ആണ്.

ഉദാഹരണം: GET /api/v1/users/25/name

ട്രാൻസ്മിഷൻ ഫോർമാറ്റിൽ നിന്നുള്ള ഡാറ്റ സ്റ്റോറേജ് ഫോർമാറ്റിന്റെ സ്വാതന്ത്ര്യം- ഒരേ ഡാറ്റ (JSON, XML, മുതലായവ) ട്രാൻസ്മിറ്റ് ചെയ്യുന്നതിനായി സെർവറിന് നിരവധി വ്യത്യസ്ത ഫോർമാറ്റുകളെ പിന്തുണയ്ക്കാൻ കഴിയും, എന്നാൽ പിന്തുണയ്ക്കുന്നതെന്തും പരിഗണിക്കാതെ തന്നെ അതിന്റെ ആന്തരിക ഫോർമാറ്റിൽ ഡാറ്റ സംഭരിക്കുന്നു.

പ്രതികരണത്തിൽ ആവശ്യമായ എല്ലാ മെറ്റാഡാറ്റയുടെയും സാന്നിധ്യം- ഡാറ്റയ്ക്ക് പുറമേ, സെർവർ അഭ്യർത്ഥന പ്രോസസ്സിംഗിന്റെ വിശദാംശങ്ങൾ നൽകണം, ഉദാഹരണത്തിന്, പിശക് സന്ദേശങ്ങൾ, അത് ഉപയോഗിച്ച് കൂടുതൽ പ്രവർത്തിക്കാൻ ആവശ്യമായ റിസോഴ്സിന്റെ വിവിധ പ്രോപ്പർട്ടികൾ, ഉദാഹരണത്തിന്, ശരിയായ ഡിസ്പ്ലേയ്ക്കായി ശേഖരത്തിലെ മൊത്തം റെക്കോർഡുകളുടെ എണ്ണം പേജ് നാവിഗേഷന്റെ. ഞങ്ങൾ പിന്നീട് വിവിധ തരത്തിലുള്ള വിഭവങ്ങളിലേക്ക് പോകും.

നമുക്ക് എന്താണ് നഷ്ടമായത്?

ക്ലാസിക് REST എന്നത് ഒരു ഫ്ലാറ്റ് ഡാറ്റ സ്റ്റോറായി സെർവറുമായി പ്രവർത്തിക്കുന്ന ക്ലയന്റ് ഉൾക്കൊള്ളുന്നു, അതേസമയം ഡാറ്റയുടെ കണക്റ്റിവിറ്റിയെയും പരസ്പരാശ്രിതത്വത്തെയും കുറിച്ച് ഒന്നും പറയുന്നില്ല. ഇതെല്ലാം, സ്ഥിരസ്ഥിതിയായി, ക്ലയന്റ് ആപ്ലിക്കേഷന്റെ ചുമലിൽ പൂർണ്ണമായും വീഴുന്നു. എന്നിരുന്നാലും, ഡാറ്റാ മാനേജ്‌മെന്റ് സിസ്റ്റങ്ങൾ വികസിപ്പിച്ചെടുത്ത ആധുനിക വിഷയ മേഖലകൾ, അത് സാമൂഹിക സേവനങ്ങളോ ഓൺലൈൻ മാർക്കറ്റിംഗ് സിസ്റ്റങ്ങളോ ആകട്ടെ, ഡാറ്റാബേസിൽ സംഭരിച്ചിരിക്കുന്ന സ്ഥാപനങ്ങൾ തമ്മിലുള്ള സങ്കീർണ്ണമായ ബന്ധത്തെ സൂചിപ്പിക്കുന്നു. ഈ കണക്ഷനുകളെ പിന്തുണയ്ക്കുന്നു, അതായത്. ഡാറ്റ സമഗ്രത എന്നത് സെർവർ ഭാഗത്തിന്റെ ഉത്തരവാദിത്തമാണ്, അതേസമയം ക്ലയന്റ് ഈ ഡാറ്റ ആക്‌സസ് ചെയ്യുന്നതിനുള്ള ഒരു ഇന്റർഫേസ് മാത്രമാണ്. അപ്പോൾ REST-ൽ നമുക്ക് എന്താണ് നഷ്ടമായത്?

ഫംഗ്ഷൻ കോളുകൾ

അവയ്‌ക്കിടയിലുള്ള ഡാറ്റയും കണക്ഷനുകളും സ്വമേധയാ മാറ്റാതിരിക്കാൻ, ഞങ്ങൾ റിസോഴ്‌സിലെ ഒരു ഫംഗ്‌ഷനെ വിളിക്കുകയും ആവശ്യമായ ഡാറ്റ ഒരു വാദമായി “ഫീഡ്” ചെയ്യുകയും ചെയ്യുന്നു. ഈ പ്രവർത്തനം REST മാനദണ്ഡങ്ങൾക്ക് അനുയോജ്യമല്ല, ഇതിന് പ്രത്യേക ക്രിയകളൊന്നുമില്ല, ഇത് ഡവലപ്പർമാരെ, ഞങ്ങളുടെ സ്വന്തം വഴിയിൽ നിന്ന് പുറത്തുകടക്കാൻ ഞങ്ങളെ പ്രേരിപ്പിക്കുന്നു.

ഏറ്റവും ലളിതമായ ഉദാഹരണം- ഉപയോക്തൃ അംഗീകാരം. ഞങ്ങൾ ലോഗിൻ ഫംഗ്‌ഷനെ വിളിക്കുന്നു, ക്രെഡൻഷ്യലുകൾ അടങ്ങിയ ഒബ്‌ജക്റ്റ് ഒരു ആർഗ്യുമെന്റായി കൈമാറുകയും പ്രതികരണമായി ഒരു ആക്‌സസ് കീ സ്വീകരിക്കുകയും ചെയ്യുന്നു. സെർവർ വശത്തെ ഡാറ്റയ്ക്ക് എന്ത് സംഭവിക്കുമെന്ന് ഞങ്ങൾ ശ്രദ്ധിക്കുന്നില്ല.

മറ്റൊരു ഓപ്ഷൻ- ഡാറ്റ തമ്മിലുള്ള കണക്ഷനുകൾ സൃഷ്ടിക്കുകയും തകർക്കുകയും ചെയ്യുന്നു. ഉദാഹരണത്തിന്, ഒരു ഗ്രൂപ്പിലേക്ക് ഒരു ഉപയോക്താവിനെ ചേർക്കുന്നത്. സ്ഥാപനത്തെ വിളിക്കുന്നു ഗ്രൂപ്പ് addUser ഫംഗ്‌ഷൻ, ഒരു ഒബ്‌ജക്റ്റ് പാരാമീറ്ററായി കൈമാറുന്നു ഉപയോക്താവ്, നമുക്ക് ഫലം ലഭിക്കും.

കൂടാതെഡാറ്റ സംഭരിക്കുന്നതുമായി നേരിട്ട് ബന്ധമില്ലാത്ത പ്രവർത്തനങ്ങളുണ്ട്, ഉദാഹരണത്തിന്, അറിയിപ്പുകൾ അയയ്ക്കൽ, ഏതെങ്കിലും പ്രവർത്തനങ്ങൾ സ്ഥിരീകരിക്കുക അല്ലെങ്കിൽ നിരസിക്കുക (റിപ്പോർട്ടിംഗ് കാലയളവ് പൂർത്തിയാക്കൽ മുതലായവ).

ഒന്നിലധികം പ്രവർത്തനങ്ങൾ

ഇത് പലപ്പോഴും സംഭവിക്കുന്നു, ക്ലയന്റ് ഡെവലപ്പർമാർ ഞാൻ എന്താണ് ഉദ്ദേശിക്കുന്നതെന്ന് മനസ്സിലാക്കും, ഒരു ക്ലയന്റ് ആപ്ലിക്കേഷന് ഒരു അഭ്യർത്ഥനയിലൂടെ ഒരേസമയം നിരവധി ഏകതാനമായ ഒബ്‌ജക്റ്റുകൾ സൃഷ്‌ടിക്കുക/മാറ്റുക/ഇല്ലാതാക്കുക/ഇല്ലാതാക്കുകയെന്നത് കൂടുതൽ സൗകര്യപ്രദമാണ്, ഓരോ ഒബ്‌ജക്റ്റിനും വ്യത്യസ്‌ത സെർവർ സൈഡ് വിധി സാധ്യമാണ്. . ഇവിടെ കുറഞ്ഞത് നിരവധി ഓപ്ഷനുകൾ ഉണ്ട്: ഒന്നുകിൽ എല്ലാ മാറ്റങ്ങളും പൂർത്തിയായി, അല്ലെങ്കിൽ അവ ഭാഗികമായി പൂർത്തിയാക്കി (ചില ഒബ്ജക്റ്റുകൾക്ക്), അല്ലെങ്കിൽ ഒരു പിശക് സംഭവിച്ചു. ശരി, നിരവധി തന്ത്രങ്ങളും ഉണ്ട്: എല്ലാവരും വിജയിച്ചാൽ മാത്രം മാറ്റങ്ങൾ പ്രയോഗിക്കുക, അല്ലെങ്കിൽ ഭാഗികമായി പ്രയോഗിക്കുക, അല്ലെങ്കിൽ എന്തെങ്കിലും പിശകുണ്ടായാൽ പിൻവലിക്കുക, ഇത് ഇതിനകം തന്നെ ഒരു പൂർണ്ണമായ ഇടപാട് സംവിധാനത്തിലേക്ക് നയിക്കുന്നു.

ഐഡിയാലിറ്റിക്കായി പരിശ്രമിക്കുന്ന ഒരു വെബ് API-യ്‌ക്ക്, അത്തരം പ്രവർത്തനങ്ങൾ എങ്ങനെയെങ്കിലും സിസ്റ്റത്തിലേക്ക് കൊണ്ടുവരാൻ ഞാൻ ആഗ്രഹിക്കുന്നു. തുടർഭാഗങ്ങളിൽ ഒന്നിൽ ഞാൻ ഇത് ചെയ്യാൻ ശ്രമിക്കും.

സ്റ്റാറ്റിസ്റ്റിക്കൽ അന്വേഷണങ്ങൾ, അഗ്രഗേറ്ററുകൾ, ഡാറ്റ ഫോർമാറ്റിംഗ്

സെർവറിൽ സംഭരിച്ചിരിക്കുന്ന ഡാറ്റയെ അടിസ്ഥാനമാക്കി, ഞങ്ങൾ ഒരു സ്റ്റാറ്റിസ്റ്റിക്കൽ സംഗ്രഹം അല്ലെങ്കിൽ ഒരു പ്രത്യേക രീതിയിൽ ഫോർമാറ്റ് ചെയ്ത ഡാറ്റ നേടേണ്ടതുണ്ട്: ഉദാഹരണത്തിന്, ക്ലയന്റ് ഭാഗത്ത് ഒരു ഗ്രാഫ് നിർമ്മിക്കാൻ. ഇത് പ്രധാനമായും ആവശ്യാനുസരണം ജനറേറ്റുചെയ്യുന്ന ഡാറ്റയാണ്, കൂടുതലോ കുറവോ പറക്കുമ്പോൾ, അത് വായിക്കാൻ മാത്രമുള്ളതാണ്, അതിനാൽ ഇത് ഒരു പ്രത്യേക വിഭാഗത്തിൽ ഉൾപ്പെടുത്തുന്നത് അർത്ഥമാക്കുന്നു. സ്റ്റാറ്റിസ്റ്റിക്കൽ ഡാറ്റയുടെ സവിശേഷമായ ഒരു സവിശേഷത, എന്റെ അഭിപ്രായത്തിൽ, അതിന് ഒരു അദ്വിതീയ ഐഡി ഇല്ല എന്നതാണ്.

യഥാർത്ഥ ആപ്ലിക്കേഷനുകൾ വികസിപ്പിക്കുമ്പോൾ നേരിടാൻ കഴിയുന്ന എല്ലാം ഇതല്ലെന്ന് എനിക്ക് ഉറപ്പുണ്ട്, നിങ്ങളുടെ കൂട്ടിച്ചേർക്കലുകളും ക്രമീകരണങ്ങളും കാണുന്നതിൽ എനിക്ക് സന്തോഷമുണ്ട്.

ഡാറ്റയുടെ തരങ്ങൾ

വസ്തുക്കൾ

ക്ലയന്റും സെർവറും തമ്മിലുള്ള ആശയവിനിമയത്തിലെ പ്രധാന ഡാറ്റ തരം ഒരു വസ്തുവാണ്. അടിസ്ഥാനപരമായി, ഒരു ഒബ്ജക്റ്റ് എന്നത് ഗുണങ്ങളുടെയും അവയുടെ അനുബന്ധ മൂല്യങ്ങളുടെയും ഒരു പട്ടികയാണ്. നമുക്ക് ഒരു അഭ്യർത്ഥനയിൽ സെർവറിലേക്ക് ഒരു ഒബ്ജക്റ്റ് അയയ്ക്കാനും അഭ്യർത്ഥന ഫലം ഒരു ഒബ്ജക്റ്റായി സ്വീകരിക്കാനും കഴിയും. എന്നിരുന്നാലും, ഒബ്‌ജക്റ്റ് ഡാറ്റാബേസിൽ സംഭരിച്ചിരിക്കുന്ന യഥാർത്ഥ എന്റിറ്റി ആയിരിക്കണമെന്നില്ല, കുറഞ്ഞത് അത് അയച്ചതോ സ്വീകരിച്ചതോ ആയ രൂപത്തിലല്ല. ഉദാഹരണത്തിന്, ഓതറൈസേഷൻ ക്രെഡൻഷ്യലുകൾ ഒരു ഒബ്ജക്റ്റായി പാസാക്കപ്പെടുന്നു, പക്ഷേ അവ ഒരു സ്വതന്ത്ര സ്ഥാപനമല്ല. ഡാറ്റാബേസിൽ സംഭരിച്ചിരിക്കുന്ന ഒബ്‌ജക്റ്റുകൾ പോലും ഒരു ഇൻട്രാ-സിസ്റ്റം സ്വഭാവത്തിന്റെ അധിക ഗുണങ്ങൾ നേടുന്നു, ഉദാഹരണത്തിന്, സൃഷ്‌ടിക്കലിന്റെയും എഡിറ്റിംഗിന്റെയും തീയതികൾ, വിവിധ സിസ്റ്റം ലേബലുകൾ, ഫ്ലാഗുകൾ. ഒബ്ജക്റ്റ് പ്രോപ്പർട്ടികൾ അവയുടെ സ്വന്തം സ്കെലാർ മൂല്യങ്ങൾ അല്ലെങ്കിൽ അടങ്ങിയിരിക്കാം ബന്ധപ്പെട്ട വസ്തുക്കൾഒപ്പം വസ്തുക്കളുടെ ശേഖരം, വസ്തുവിന്റെ ഭാഗമല്ലാത്തവ. ചില ഒബ്ജക്റ്റ് പ്രോപ്പർട്ടികൾ എഡിറ്റ് ചെയ്യാവുന്നതാണ്, ചിലത് സിസ്റ്റം പ്രോപ്പർട്ടികൾ, റീഡ്-ഒൺലി, ചിലത് സ്ഥിതിവിവരക്കണക്ക് സ്വഭാവമുള്ളതും ഫ്ലൈയിൽ കണക്കുകൂട്ടുന്നതും (ഉദാഹരണത്തിന്, ലൈക്കുകളുടെ എണ്ണം). ഉപയോക്താവിന്റെ അവകാശങ്ങൾ അനുസരിച്ച് ചില ഒബ്ജക്റ്റ് പ്രോപ്പർട്ടികൾ മറച്ചിരിക്കാം.

വസ്തുക്കളുടെ ശേഖരം

ഞങ്ങൾ ശേഖരങ്ങളെക്കുറിച്ച് സംസാരിക്കുമ്പോൾ, ഏകതാനമായ ഒബ്‌ജക്റ്റുകളുടെ ഒരു ലിസ്റ്റ് ഉപയോഗിച്ച് പ്രവർത്തിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്ന ഒരു തരം സെർവർ ഉറവിടമാണ് ഞങ്ങൾ അർത്ഥമാക്കുന്നത്, അതായത്. ഒബ്ജക്റ്റുകൾ ചേർക്കുക, ഇല്ലാതാക്കുക, മാറ്റുക, അവയിൽ നിന്ന് തിരഞ്ഞെടുക്കുക. കൂടാതെ, ഒരു ശേഖരത്തിന് സൈദ്ധാന്തികമായി അതിന്റേതായ സവിശേഷതകളും (ഉദാഹരണത്തിന്, ഒരു പേജിലെ പരമാവധി ഘടകങ്ങളുടെ എണ്ണം) ഫംഗ്ഷനുകളും (ഞാൻ ഇവിടെ ആശയക്കുഴപ്പത്തിലാണ്, പക്ഷേ ഇതും സംഭവിച്ചു).

സ്കെയിലർ മൂല്യങ്ങൾ

അവയുടെ ശുദ്ധമായ രൂപത്തിൽ, ഒരു പ്രത്യേക സ്ഥാപനമെന്ന നിലയിൽ സ്കെയിലർ മൂല്യങ്ങൾ എന്റെ ഓർമ്മയിൽ വളരെ വിരളമാണ്. സാധാരണയായി അവ ഒബ്‌ജക്‌റ്റുകളുടെയോ ശേഖരങ്ങളുടെയോ പ്രോപ്പർട്ടികൾ ആയി പ്രത്യക്ഷപ്പെട്ടു, അതുപോലെ അവ വായിക്കാനോ എഴുതാനോ കഴിയും. ഉദാഹരണത്തിന്, GET /users/1/name ഉപയോഗിച്ച് ഉപയോക്തൃനാമം വീണ്ടെടുക്കാനും വ്യക്തിഗതമായി മാറ്റാനും കഴിയും. പ്രായോഗികമായി, ഈ സവിശേഷത വളരെ അപൂർവമായി മാത്രമേ ഉപയോഗപ്രദമാകൂ, പക്ഷേ ആവശ്യമെങ്കിൽ, അത് കയ്യിൽ കരുതാൻ ഞാൻ ആഗ്രഹിക്കുന്നു. റെക്കോർഡുകളുടെ എണ്ണം (ഫിൽട്ടറിംഗ് ഉള്ളതോ അല്ലാതെയോ): GET /news/count .

ഇനിപ്പറയുന്ന ലേഖനങ്ങളിലൊന്നിൽ, ഈ പ്രവർത്തനങ്ങളെ തരംതിരിക്കാനും സാധ്യമായ അഭ്യർത്ഥനകൾക്കും ഉത്തരങ്ങൾക്കുമുള്ള ഓപ്ഷനുകൾ വാഗ്ദാനം ചെയ്യാനും ഞാൻ ശ്രമിക്കും, അവയിൽ ഏതാണ് ഞാൻ പ്രായോഗികമായി നേരിട്ടത് എന്നതിനെ അടിസ്ഥാനമാക്കി.

ഏകദേശം രണ്ട്: ശരിയായ പാത

ഈ സമീപനത്തിൽ, നിങ്ങളുടെ വെബ് API-യുടെ ഉറവിടങ്ങളിലേക്കും രീതികളിലേക്കും തനതായ പാതകൾ നിർമ്മിക്കുന്നതിനുള്ള സമീപനങ്ങളെക്കുറിച്ചും ഈ പാതയുടെ രൂപത്തെയും അതിന്റെ ഘടകങ്ങളെയും ബാധിക്കുന്ന ആപ്ലിക്കേഷന്റെ ആർക്കിടെക്ചറൽ സവിശേഷതകളെക്കുറിച്ചും പ്രത്യേകം സംസാരിക്കാൻ ഞാൻ ആഗ്രഹിക്കുന്നു.

കരയിൽ നിൽക്കുമ്പോൾ എന്താണ് ചിന്തിക്കേണ്ടത്

പതിപ്പ്

താമസിയാതെ അല്ലെങ്കിൽ പിന്നീട്, ഏതൊരു ഓപ്പറേറ്റിംഗ് സിസ്റ്റവും വികസിക്കാൻ തുടങ്ങുന്നു: വികസിപ്പിക്കുക, കൂടുതൽ സങ്കീർണ്ണമാവുക, സ്കെയിൽ ചെയ്യുക, കൂടുതൽ ആധുനികമാവുക. REST API ഡവലപ്പർമാരെ സംബന്ധിച്ചിടത്തോളം, ഇത് പഴയത് പ്രവർത്തിക്കുമ്പോൾ API-യുടെ പുതിയ പതിപ്പുകൾ സമാരംഭിക്കേണ്ടതിന്റെ ആവശ്യകതയിൽ നിറഞ്ഞതാണ്. ഇവിടെ ഞാൻ ഇനി സംസാരിക്കുന്നത് നിങ്ങളുടെ സിസ്റ്റത്തിന് കീഴിലുള്ള വാസ്തുവിദ്യാ മാറ്റങ്ങളെക്കുറിച്ചല്ല, മറിച്ച് ഡാറ്റ ഫോർമാറ്റും അതുമായുള്ള പ്രവർത്തനങ്ങളുടെ സെറ്റും മാറിക്കൊണ്ടിരിക്കുന്നതിനെക്കുറിച്ചാണ്. ഏത് സാഹചര്യത്തിലും, സോഴ്‌സ് കോഡിന്റെ പ്രാരംഭ ഓർഗനൈസേഷനിലും URL നിർമ്മാണ തത്വത്തിലും പതിപ്പിംഗ് നൽകണം. URL-കളുടെ കാര്യം വരുമ്പോൾ, അഭ്യർത്ഥന അഭിസംബോധന ചെയ്യുന്ന API-യുടെ പതിപ്പ് സൂചിപ്പിക്കാൻ ഏറ്റവും ജനപ്രിയമായ രണ്ട് വഴികളുണ്ട്. v1.example-api.com ഉപഡൊമെയ്‌ൻ തലത്തിൽ example-api.com/v1/ പാത്ത് പ്രിഫിക്‌സ് ചെയ്യുകയും പതിപ്പുകൾ വേർതിരിക്കുകയും ചെയ്യുന്നു. നിങ്ങളുടെ ആവശ്യങ്ങളും ആവശ്യങ്ങളും അനുസരിച്ച് നിങ്ങൾക്ക് അവയിലേതെങ്കിലും ഉപയോഗിക്കാം.

ഘടകങ്ങളുടെ സ്വയംഭരണം

ഒന്നിലധികം ഉപയോക്തൃ റോളുകളെ പിന്തുണയ്ക്കുന്ന സങ്കീർണ്ണമായ സിസ്റ്റങ്ങളുടെ വെബ് എപിഐയ്ക്ക് പലപ്പോഴും ഭാഗങ്ങളായി വിഭജിക്കേണ്ടതുണ്ട്, അവയിൽ ഓരോന്നിനും അതിന്റേതായ ചുമതലകൾ നൽകുന്നു. വാസ്തവത്തിൽ, ഓരോ ഭാഗവും വ്യത്യസ്ത ഫിസിക്കൽ മെഷീനുകളിലും പ്ലാറ്റ്ഫോമുകളിലും പ്രവർത്തിക്കുന്ന ഒരു സ്വതന്ത്ര ആപ്ലിക്കേഷനാകാം. API വിവരിക്കുന്ന സന്ദർഭത്തിൽ, സെർവർ അഭ്യർത്ഥന എങ്ങനെ പ്രോസസ്സ് ചെയ്യുന്നുവെന്നും ഇതിൽ എന്ത് ശക്തികളും സാങ്കേതികവിദ്യകളും ഉൾപ്പെട്ടിരിക്കുന്നു എന്നതും ഞങ്ങൾക്ക് പ്രധാനമല്ല. ക്ലയന്റിനെ സംബന്ധിച്ചിടത്തോളം, API ഒരു എൻക്യാപ്‌സുലേറ്റഡ് സിസ്റ്റമാണ്. എന്നിരുന്നാലും, സിസ്റ്റത്തിന്റെ വിവിധ ഭാഗങ്ങൾക്ക് തികച്ചും വ്യത്യസ്തമായ പ്രവർത്തനക്ഷമത ഉണ്ടായിരിക്കാം, ഉദാഹരണത്തിന്, അഡ്മിനിസ്ട്രേറ്റീവ്, യൂസർ ഭാഗങ്ങൾ. ഒരേ സ്രോതസ്സുകളിൽ പ്രവർത്തിക്കുന്നതിനുള്ള രീതിശാസ്ത്രത്തിൽ കാര്യമായ വ്യത്യാസമുണ്ടാകാം. അതിനാൽ, അത്തരം ഭാഗങ്ങൾ admin.v1.example-api.com ഡൊമെയ്ൻ അല്ലെങ്കിൽ example-api.com/v1/admin/ പാത്ത് പ്രിഫിക്സിന്റെ തലത്തിൽ വേർതിരിക്കേണ്ടതാണ്. ഈ ആവശ്യകത നിർബന്ധമല്ല, കൂടാതെ സിസ്റ്റത്തിന്റെ സങ്കീർണ്ണതയെയും അതിന്റെ ഉദ്ദേശ്യത്തെയും ആശ്രയിച്ചിരിക്കുന്നു.

ഡാറ്റ എക്സ്ചേഞ്ച് ഫോർമാറ്റ്

ഏറ്റവും സൗകര്യപ്രദവും പ്രവർത്തനപരവുമാണ്, എന്റെ അഭിപ്രായത്തിൽ, ഡാറ്റാ എക്സ്ചേഞ്ച് ഫോർമാറ്റ് JSON ആണ്, എന്നാൽ ഡാറ്റ തരം നഷ്‌ടപ്പെടാതെ സീരിയലൈസ് ചെയ്‌ത ഒബ്‌ജക്റ്റുകൾ സംഭരിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്ന XML, YAML അല്ലെങ്കിൽ മറ്റേതെങ്കിലും ഫോർമാറ്റിന്റെ ഉപയോഗം ആരും നിരോധിക്കുന്നില്ല. വേണമെങ്കിൽ, നിങ്ങൾക്ക് API പിന്തുണ ഒന്നിലധികം ഇൻപുട്ട്/ഔട്ട്പുട്ട് ഫോർമാറ്റുകൾ ആക്കാം. ആവശ്യമുള്ള സ്വീകരിക്കുന്ന പ്രതികരണ ഫോർമാറ്റ് സൂചിപ്പിക്കാൻ HTTP അഭ്യർത്ഥന തലക്കെട്ടും അഭ്യർത്ഥനയിൽ കൈമാറിയ ഡാറ്റയുടെ ഫോർമാറ്റ് സൂചിപ്പിക്കാൻ ഉള്ളടക്ക തരവും ഉപയോഗിച്ചാൽ മതി. റിസോഴ്‌സ് URL-ലേക്ക് ഒരു വിപുലീകരണം ചേർക്കുക എന്നതാണ് മറ്റൊരു ജനപ്രിയ മാർഗം, ഉദാഹരണത്തിന്, GET /users.xml, എന്നാൽ ഈ രീതി വഴക്കമുള്ളതും മനോഹരവുമാണെന്ന് തോന്നുന്നു, കാരണം ഇത് URL ഭാരമുള്ളതാക്കുകയും സാധ്യമായ എല്ലാത്തിനും പകരം GET അഭ്യർത്ഥനകൾക്ക് ശരിയുമാണ്. പ്രവർത്തനങ്ങൾ.

പ്രാദേശികവൽക്കരണവും ബഹുഭാഷാവാദവും

പ്രായോഗികമായി, API ബഹുഭാഷാവൽക്കരണം മിക്കപ്പോഴും അന്തിമ ഉപയോക്താവിന് നേരിട്ട് പ്രദർശിപ്പിക്കുന്നതിന് ആവശ്യമായ ഭാഷയിലേക്ക് സേവനവും പിശക് സന്ദേശങ്ങളും വിവർത്തനം ചെയ്യുന്നതിലേക്ക് വരുന്നു. ബഹുഭാഷാ ഉള്ളടക്കത്തിനും അതിന്റേതായ സ്ഥാനമുണ്ട്, എന്നാൽ വ്യത്യസ്ത ഭാഷകളിൽ ഉള്ളടക്കം സംരക്ഷിക്കുന്നതും നൽകുന്നതും കൂടുതൽ വ്യക്തമായി വേർതിരിക്കേണ്ടതാണ്, ഉദാഹരണത്തിന്, നിങ്ങൾക്ക് വ്യത്യസ്ത ഭാഷകളിൽ ഒരേ ലേഖനമുണ്ടെങ്കിൽ, വാസ്തവത്തിൽ ഇവ രണ്ട് വ്യത്യസ്ത എന്റിറ്റികളാണ്, ഗ്രൂപ്പ് ഉള്ളടക്കത്തിന്റെ ഐക്യത്തിന്റെ അടയാളം. പ്രതീക്ഷിക്കുന്ന ഭാഷ തിരിച്ചറിയാൻ വിവിധ രീതികൾ ഉപയോഗിക്കാം. ഏറ്റവും ലളിതമായത് സ്റ്റാൻഡേർഡ് HTTP തലക്കെട്ട് സ്വീകരിക്കുക-ഭാഷയാണ്. ഒരു GET പാരാമീറ്റർ language="en" ചേർക്കുന്നത്, ഉദാഹരണം-api.com/en/ എന്ന പാത്ത് പ്രിഫിക്‌സ് ഉപയോഗിച്ച് അല്ലെങ്കിൽ en.example-api.com എന്ന ഡൊമെയ്‌ൻ നെയിം ലെവലിൽ പോലും ഞാൻ മറ്റ് വഴികൾ കണ്ടു. ലൊക്കേൽ എങ്ങനെ വ്യക്തമാക്കണം എന്നതിന്റെ തിരഞ്ഞെടുപ്പ് നിർദ്ദിഷ്ട ആപ്ലിക്കേഷനെയും അത് അഭിമുഖീകരിക്കുന്ന ജോലികളെയും ആശ്രയിച്ചിരിക്കുന്നുവെന്ന് എനിക്ക് തോന്നുന്നു.

ആന്തരിക റൂട്ടിംഗ്

അതിനാൽ ഞങ്ങൾ ഞങ്ങളുടെ API യുടെ (അല്ലെങ്കിൽ അതിന്റെ ഘടകങ്ങളിൽ ഒന്ന്) റൂട്ട് നോഡിൽ എത്തി. തുടർന്നുള്ള എല്ലാ റൂട്ടുകളും നിങ്ങളുടെ സെർവർ ആപ്ലിക്കേഷനിൽ അത് പിന്തുണയ്‌ക്കുന്ന ഉറവിടങ്ങളുടെ കൂട്ടത്തിന് അനുസൃതമായി നേരിട്ട് നടക്കും.

ശേഖരണ പാതകൾ

ശേഖരത്തിലേക്കുള്ള പാത വ്യക്തമാക്കുന്നതിന്, ഞങ്ങൾ അനുബന്ധ എന്റിറ്റിയുടെ പേര് ഉപയോഗിക്കുന്നു, ഉദാഹരണത്തിന്, ഇത് ഉപയോക്താക്കളുടെ ഒരു ലിസ്റ്റ് ആണെങ്കിൽ, പാത /ഉപയോക്താക്കൾ ആയിരിക്കും. ശേഖരത്തിന് രണ്ട് രീതികൾ ബാധകമാണ്: GET (എന്റിറ്റികളുടെ പരിമിതമായ ലിസ്റ്റ് സ്വീകരിക്കുന്നു), POST (ഒരു പുതിയ ഘടകം സൃഷ്ടിക്കൽ). ലിസ്റ്റുകൾക്കായുള്ള അഭ്യർത്ഥനകളിൽ, പേജിംഗ്, സോർട്ടിംഗ്, ഫിൽട്ടറിംഗ്, സെർച്ചിംഗ് മുതലായവയ്‌ക്കായി ഉപയോഗിക്കുന്ന നിരവധി അധിക GET പാരാമീറ്ററുകൾ നമുക്ക് ഉപയോഗിക്കാം, പക്ഷേ അവ ഓപ്‌ഷണൽ ആയിരിക്കണം, അതായത്. ഈ പാരാമീറ്ററുകൾ പാതയുടെ ഭാഗമായി കടന്നുപോകാൻ പാടില്ല!

ശേഖരണ ഘടകങ്ങൾ

ഒരു നിർദ്ദിഷ്‌ട ശേഖരണ ഘടകം ആക്‌സസ് ചെയ്യുന്നതിന്, റൂട്ടിൽ ഞങ്ങൾ അതിന്റെ തനതായ ഐഡന്റിഫയർ /ഉപയോക്താക്കൾ/25 ഉപയോഗിക്കുന്നു. അതിലേക്കുള്ള അതുല്യമായ പാതയാണിത്. ഒരു ഒബ്‌ജക്‌റ്റിനൊപ്പം പ്രവർത്തിക്കാൻ, GET (ഒരു ഒബ്‌ജക്റ്റ് നേടൽ), പുട്ട്/പാച്ച് (മാറ്റം), ഇല്ലാതാക്കൽ (ഇല്ലാതാക്കൽ) എന്നീ രീതികൾ ബാധകമാണ്.

അതുല്യമായ വസ്തുക്കൾ

നിലവിലെ ഉപയോക്താവിന്റെ പ്രൊഫൈൽ /പ്രൊഫൈൽ , അല്ലെങ്കിൽ വ്യക്തിഗത ക്രമീകരണങ്ങൾ / ക്രമീകരണങ്ങൾ പോലുള്ള നിലവിലെ ഉപയോക്താവിന് തനതായ ഒബ്‌ജക്റ്റുകൾ പല സേവനങ്ങളിലും ഉണ്ട്. തീർച്ചയായും, ഒരു വശത്ത്, ഇവ ഒരു ശേഖരത്തിന്റെ ഘടകങ്ങളാണ്, എന്നാൽ ക്ലയന്റ് ആപ്ലിക്കേഷൻ ഞങ്ങളുടെ വെബ് API ഉപയോഗിക്കുന്നതിനുള്ള ആരംഭ പോയിന്റാണ് അവ, കൂടാതെ ഡാറ്റയിൽ കൂടുതൽ വിപുലമായ പ്രവർത്തനങ്ങളും അനുവദിക്കുന്നു. ഈ സാഹചര്യത്തിൽ, സുരക്ഷയുടെയും ഡാറ്റയുടെ രഹസ്യാത്മകതയുടെയും കാരണങ്ങളാൽ, ഉപയോക്തൃ ക്രമീകരണങ്ങൾ സംഭരിക്കുന്ന ശേഖരം പൂർണ്ണമായും ആക്സസ് ചെയ്യാൻ കഴിയില്ല.

വസ്തുക്കളുടെയും ശേഖരങ്ങളുടെയും സവിശേഷതകൾ

ഒരു ഒബ്‌ജക്‌റ്റിന്റെ ഏതെങ്കിലും പ്രോപ്പർട്ടികൾ നേരിട്ട് ലഭിക്കുന്നതിന്, വസ്തുവിന്റെ പാതയിലേക്ക് പ്രോപ്പർട്ടി നാമം ചേർത്താൽ മതിയാകും, ഉദാഹരണത്തിന്, ഉപയോക്തൃനാമം /users/25/name . GET (ഒരു മൂല്യം നേടൽ), PUT/PATCH (ഒരു മൂല്യം മാറ്റൽ) എന്നീ രീതികൾ ഒരു പ്രോപ്പർട്ടിക്ക് ബാധകമാണ്. കാരണം DELETE രീതി ബാധകമല്ല ഒരു വസ്തുവിന്റെ ഘടനാപരമായ ഭാഗമാണ്, ഡാറ്റയുടെ ഔപചാരികമായ യൂണിറ്റ്.

മുമ്പത്തെ ഭാഗത്ത്, വസ്തുക്കളെപ്പോലെ ശേഖരങ്ങൾക്കും അവരുടേതായ ഗുണങ്ങളുണ്ടാകുമെന്ന വസ്തുതയെക്കുറിച്ച് ഞങ്ങൾ സംസാരിച്ചു. എന്റെ അനുഭവത്തിൽ, എനിക്ക് ഉപയോഗപ്രദമെന്ന് തോന്നിയ ഒരേയൊരു പ്രോപ്പർട്ടി കൗണ്ട് പ്രോപ്പർട്ടി മാത്രമാണ്, എന്നാൽ നിങ്ങളുടെ അപേക്ഷ കൂടുതൽ സങ്കീർണ്ണവും നിർദ്ദിഷ്ടവുമാകാം. ശേഖരണ ഗുണങ്ങളിലേക്കുള്ള പാതകൾ അവയുടെ മൂലകങ്ങളുടെ ഗുണങ്ങളുടെ അതേ തത്വമനുസരിച്ചാണ് നിർമ്മിച്ചിരിക്കുന്നത്: /users/count . ശേഖരണ പ്രോപ്പർട്ടികൾക്ക്, GET (ഒരു പ്രോപ്പർട്ടി നേടൽ) രീതി മാത്രമേ ബാധകമാകൂ ഒരു ലിസ്റ്റ് ആക്‌സസ് ചെയ്യുന്നതിനുള്ള ഒരു ഇന്റർഫേസ് മാത്രമാണ് ശേഖരം.

ബന്ധപ്പെട്ട വസ്തുക്കളുടെ ശേഖരം

ഒരു തരം ഒബ്‌ജക്റ്റ് പ്രോപ്പർട്ടി ബന്ധപ്പെട്ട ഒബ്‌ജക്റ്റുകളോ അനുബന്ധ വസ്തുക്കളുടെ ശേഖരമോ ആകാം. അത്തരം എന്റിറ്റികൾ, ഒരു ചട്ടം പോലെ, ഒരു വസ്തുവിന്റെ സ്വന്തം സ്വത്തല്ല, മറിച്ച് മറ്റ് എന്റിറ്റികളുമായുള്ള അതിന്റെ ബന്ധങ്ങളെ മാത്രം പരാമർശിക്കുന്നു. ഉദാഹരണത്തിന്, /users/25/roles എന്ന ഉപയോക്താവിന് നൽകിയിട്ടുള്ള റോളുകളുടെ ഒരു ലിസ്റ്റ്. ഇനിപ്പറയുന്ന ഭാഗങ്ങളിലൊന്നിൽ നെസ്റ്റഡ് ഒബ്‌ജക്റ്റുകളും ശേഖരങ്ങളും ഉപയോഗിച്ച് പ്രവർത്തിക്കുന്നതിനെക്കുറിച്ച് ഞങ്ങൾ വിശദമായി സംസാരിക്കും, എന്നാൽ ഈ ഘട്ടത്തിൽ ഒരു ഒബ്‌ജക്റ്റിന്റെ മറ്റേതെങ്കിലും പ്രോപ്പർട്ടി പോലെ അവ നേരിട്ട് ആക്‌സസ് ചെയ്യാനുള്ള കഴിവ് ഞങ്ങൾക്ക് മതിയാകും.

വസ്തുക്കളുടെയും ശേഖരങ്ങളുടെയും പ്രവർത്തനങ്ങൾ

ഒരു ശേഖരത്തിന്റെയോ ഒബ്‌ജക്റ്റിന്റെയോ ഫംഗ്‌ഷൻ കോൾ ഇന്റർഫേസിലേക്കുള്ള പാത നിർമ്മിക്കുന്നതിന്, ഒരു പ്രോപ്പർട്ടി ആക്‌സസ് ചെയ്യുന്നതിന് ഞങ്ങൾ അതേ സമീപനം ഉപയോഗിക്കുന്നു. ഉദാഹരണത്തിന്, /users/25/sendPasswordReminder ഒബ്ജക്റ്റിനോ /users/disableUnconfirmed ശേഖരത്തിനോ വേണ്ടി. ഫംഗ്‌ഷൻ കോളുകൾക്കായി, ഞങ്ങൾ എപ്പോഴും POST രീതി ഉപയോഗിക്കുന്നു. എന്തുകൊണ്ട്? ക്ലാസിക് REST-ൽ ഫംഗ്‌ഷനുകൾ വിളിക്കുന്നതിന് പ്രത്യേക ക്രിയകളൊന്നുമില്ലെന്നും അതിനാൽ നിലവിലുള്ളവയിൽ ഒന്ന് ഉപയോഗിക്കേണ്ടിവരുമെന്നും ഞാൻ നിങ്ങളെ ഓർമ്മിപ്പിക്കട്ടെ. എന്റെ അഭിപ്രായത്തിൽ, POST രീതി ഇതിന് ഏറ്റവും അനുയോജ്യമാണ് കാരണം... സെർവറിലേക്ക് ആവശ്യമായ ആർഗ്യുമെന്റുകൾ കൈമാറാൻ ഇത് നിങ്ങളെ അനുവദിക്കുന്നു, അത് അസാധുവായതല്ല (ഒന്നിലധികം തവണ ആക്‌സസ് ചെയ്യുമ്പോൾ അതേ ഫലം നൽകുന്നു), കൂടാതെ സെമാന്റിക്‌സിലെ ഏറ്റവും അമൂർത്തവുമാണ്.

എല്ലാം കൂടുതലോ കുറവോ സിസ്റ്റത്തിൽ ചേരുമെന്ന് ഞാൻ പ്രതീക്ഷിക്കുന്നു :) അടുത്ത ഭാഗത്ത് ഞങ്ങൾ അഭ്യർത്ഥനകളും പ്രതികരണങ്ങളും, അവയുടെ ഫോർമാറ്റുകൾ, സ്റ്റാറ്റസ് കോഡുകൾ എന്നിവയെക്കുറിച്ച് കൂടുതൽ വിശദമായി സംസാരിക്കും.

ഏകദേശ മൂന്ന്: ചോദ്യങ്ങളും ഉത്തരങ്ങളും

മുമ്പത്തെ ഏകദേശങ്ങളിൽ, വെബ് എപിഐ വികസനത്തിൽ നിലവിലുള്ള അനുഭവം ശേഖരിക്കുന്നതിനും സംഗ്രഹിക്കുന്നതിനുമുള്ള ആശയം എങ്ങനെയാണ് വന്നതെന്ന് ഞാൻ സംസാരിച്ചു. ആദ്യ ഭാഗത്ത്, ഒരു വെബ് API രൂപകൽപന ചെയ്യുമ്പോൾ ഞങ്ങൾ കൈകാര്യം ചെയ്യുന്ന ഉറവിടങ്ങളും പ്രവർത്തനങ്ങളും എന്തൊക്കെയാണെന്ന് വിവരിക്കാൻ ഞാൻ ശ്രമിച്ചു. ഈ ഉറവിടങ്ങൾ ആക്‌സസ് ചെയ്യുന്നതിനായി തനതായ URL-കൾ നിർമ്മിക്കുന്നതിനുള്ള പ്രശ്‌നങ്ങളെ രണ്ടാം ഭാഗം സ്പർശിച്ചു. ഈ ഏകദേശ കണക്കിൽ, അഭ്യർത്ഥനകൾക്കും പ്രതികരണങ്ങൾക്കും സാധ്യമായ ഓപ്ഷനുകൾ വിവരിക്കാൻ ഞാൻ ശ്രമിക്കും.

സാർവത്രിക ഉത്തരം

സെർവറും ക്ലയന്റും തമ്മിലുള്ള ആശയവിനിമയത്തിന്റെ നിർദ്ദിഷ്ട ഫോർമാറ്റ് ഡെവലപ്പറുടെ വിവേചനാധികാരത്തിൽ ആയിരിക്കാമെന്ന് ഞങ്ങൾ ഇതിനകം പറഞ്ഞിട്ടുണ്ട്. എന്നെ സംബന്ധിച്ചിടത്തോളം, JSON ഫോർമാറ്റ് ഏറ്റവും സൗകര്യപ്രദവും ദൃശ്യപരവുമാണെന്ന് തോന്നുന്നു, എന്നിരുന്നാലും ഒരു യഥാർത്ഥ ആപ്ലിക്കേഷൻ നിരവധി ഫോർമാറ്റുകളെ പിന്തുണച്ചേക്കാം. ഇപ്പോൾ പ്രതികരണ ഒബ്‌ജക്റ്റിന്റെ ഘടനയിലും ആവശ്യമായ ആട്രിബ്യൂട്ടുകളിലും ശ്രദ്ധ കേന്ദ്രീകരിക്കാം. അതെ, സെർവർ നൽകുന്ന എല്ലാ ഡാറ്റയും ഞങ്ങൾ ഒരു പ്രത്യേക കണ്ടെയ്‌നറിൽ പൊതിയുന്നതാണ് - പൊതുവായ പ്രതികരണ വസ്തു, കൂടുതൽ പ്രോസസ്സിംഗിന് ആവശ്യമായ എല്ലാ സേവന വിവരങ്ങളും ഇതിൽ അടങ്ങിയിരിക്കും. അപ്പോൾ, ഈ വിവരം എന്താണ്:

വിജയം - അഭ്യർത്ഥനയുടെ വിജയത്തിന്റെ അടയാളം

അഭ്യർത്ഥന വിജയകരമാണോ എന്ന് സെർവറിൽ നിന്ന് ഒരു പ്രതികരണം ലഭിക്കുമ്പോൾ ഉടനടി മനസ്സിലാക്കാനും അത് ഉചിതമായ ഹാൻഡ്‌ലർക്ക് കൈമാറാനും, “വിജയം” എന്ന ടോക്കൺ ഉപയോഗിച്ചാൽ മതിയാകും. ഡാറ്റ ഇല്ലാത്ത ഏറ്റവും ലളിതമായ സെർവർ പ്രതികരണം ഇതുപോലെ കാണപ്പെടും:

POST /api/v1/ലേഖനങ്ങൾ/22/പ്രസിദ്ധീകരണം ("വിജയം": സത്യം)

പിശക് - പിശക് വിവരം

അഭ്യർത്ഥന പരാജയപ്പെടുകയാണെങ്കിൽ - നെഗറ്റീവ് സെർവർ പ്രതികരണങ്ങളുടെ കാരണങ്ങളെയും തരങ്ങളെയും കുറിച്ച് ഞങ്ങൾ കുറച്ച് കഴിഞ്ഞ് സംസാരിക്കും - പ്രതികരണത്തിലേക്ക് “പിശക്” ആട്രിബ്യൂട്ട് ചേർത്തു, അതിൽ HTTP സ്റ്റാറ്റസ് കോഡും പിശക് സന്ദേശത്തിന്റെ വാചകവും അടങ്ങിയിരിക്കുന്നു. എന്നതിനെക്കുറിച്ചുള്ള സന്ദേശങ്ങളുമായി ദയവായി ആശയക്കുഴപ്പത്തിലാക്കരുത് മൂല്യനിർണ്ണയ പിശകുകൾനിർദ്ദിഷ്ട ഫീൽഡുകൾക്കുള്ള ഡാറ്റ. എന്റെ അഭിപ്രായത്തിൽ, പ്രതികരണ തലക്കെട്ടിൽ സ്റ്റാറ്റസ് കോഡ് നൽകുന്നത് ഏറ്റവും ശരിയാണ്, പക്ഷേ മറ്റൊരു സമീപനവും ഞാൻ കണ്ടു - എല്ലായ്പ്പോഴും തലക്കെട്ടിൽ സ്റ്റാറ്റസ് 200 (വിജയം) തിരികെ നൽകുക, കൂടാതെ വിശദാംശങ്ങളും സാധ്യമായ പിശക് ഡാറ്റയും അയയ്ക്കുക പ്രതികരണം.

GET /api/v1/user ("വിജയം": തെറ്റ്, "പിശക്": ("കോഡ്": 401, "സന്ദേശം": "അംഗീകാരം പരാജയപ്പെട്ടു"))

ഡാറ്റ - സെർവർ നൽകുന്ന ഡാറ്റ

മിക്ക സെർവർ പ്രതികരണങ്ങളും ഡാറ്റ തിരികെ നൽകുന്നതിനാണ് രൂപകൽപ്പന ചെയ്തിരിക്കുന്നത്. അഭ്യർത്ഥനയുടെ തരത്തെയും അതിന്റെ വിജയത്തെയും ആശ്രയിച്ച്, പ്രതീക്ഷിക്കുന്ന ഡാറ്റാ സെറ്റ് വ്യത്യാസപ്പെടും, എന്നിരുന്നാലും, ബഹുഭൂരിപക്ഷം പ്രതികരണങ്ങളിലും "ഡാറ്റ" ആട്രിബ്യൂട്ട് ഉണ്ടായിരിക്കും.

വിജയകരമാണെങ്കിൽ തിരികെ നൽകിയ ഡാറ്റയുടെ ഉദാഹരണം. ഈ സാഹചര്യത്തിൽ, പ്രതികരണത്തിൽ അഭ്യർത്ഥിച്ച ഉപയോക്തൃ ഒബ്ജക്റ്റ് അടങ്ങിയിരിക്കുന്നു.

GET /api/v1/user ("വിജയം": true, "data": ( "id": 125, "email": " [ഇമെയിൽ പരിരക്ഷിതം]", "പേര്" : "ജോൺ", "കുടുംബപ്പേര്" : "സ്മിത്ത്", ) )

ഒരു പിശക് സംഭവിച്ചാൽ തിരികെ നൽകിയ ഡാറ്റയുടെ ഒരു ഉദാഹരണം. ഈ സാഹചര്യത്തിൽ, അതിൽ ഫീൽഡ് നാമങ്ങളും മൂല്യനിർണ്ണയ പിശക് സന്ദേശങ്ങളും അടങ്ങിയിരിക്കുന്നു.

PUT /api/v1/user ( "വിജയം": തെറ്റ്, "പിശക്": ( "കോഡ്" : 422, "സന്ദേശം" : "സാധുവാക്കൽ പരാജയപ്പെട്ടു" ) "ഡാറ്റ": ( "ഇമെയിൽ" : "ഇമെയിൽ ശൂന്യമാക്കാൻ കഴിയില്ല. ",))

പേജിനേഷൻ - പേജ് നാവിഗേഷൻ സംഘടിപ്പിക്കുന്നതിന് ആവശ്യമായ വിവരങ്ങൾ

ഡാറ്റയ്‌ക്ക് പുറമേ, മടങ്ങിവരുന്ന പ്രതികരണങ്ങളിൽ ശേഖരണ ഘടകങ്ങളുടെ ഒരു കൂട്ടം, അന്വേഷണ ഫലങ്ങളെ അടിസ്ഥാനമാക്കിയുള്ള പേജ് നാവിഗേഷൻ (പാജിനേഷൻ) സംബന്ധിച്ച വിവരങ്ങൾ ഉണ്ടായിരിക്കണം.

പേജിനേഷനായുള്ള ഏറ്റവും കുറഞ്ഞ മൂല്യങ്ങളുടെ കൂട്ടത്തിൽ ഇവ ഉൾപ്പെടുന്നു:

• റെക്കോർഡുകളുടെ ആകെ എണ്ണം;
• പേജുകളുടെ എണ്ണം;
• നിലവിലെ പേജ് നമ്പറുകൾ;
• ഒരു പേജിലെ റെക്കോർഡുകളുടെ എണ്ണം;
• സെർവർ സൈഡ് പിന്തുണയ്ക്കുന്ന ഓരോ പേജിനും പരമാവധി റെക്കോർഡുകൾ.

ചില വെബ് API ഡവലപ്പർമാർ പേജിനേഷനിൽ അടുത്തുള്ള പേജുകളിലേക്കുള്ള ഒരു കൂട്ടം റെഡിമെയ്ഡ് ലിങ്കുകളും അതുപോലെ ആദ്യത്തേതും അവസാനത്തേതും നിലവിലുള്ളതും ഉൾക്കൊള്ളുന്നു.

GET /api/v1/ലേഖനങ്ങളുടെ പ്രതികരണം: ( "വിജയം": സത്യം, "ഡാറ്റ": [ ( "id" : 1, "title" : "രസകരമായ കാര്യം", ), ( "id" : 2, "title" : "ബോറടിക്കുന്ന വാചകം", ) ], "പേജിനേഷൻ": ( "മൊത്തം രേഖകൾ" : 2, "മൊത്തം പേജുകൾ" : 1, "നിലവിലെ പേജ്" : 1, "പെർപേജ്" : 20, "maxPerPage" : 100, ) )

തെറ്റുകളിൽ പ്രവർത്തിക്കുക

മുകളിൽ സൂചിപ്പിച്ചതുപോലെ, വെബ് API-യിലേക്കുള്ള എല്ലാ അഭ്യർത്ഥനകളും വിജയകരമല്ല, എന്നാൽ ഇതും ഗെയിമിന്റെ ഭാഗമാണ്. ഒരു പിശക് റിപ്പോർട്ടിംഗ് സിസ്റ്റം എന്നത് ക്ലയന്റ് ജോലി എളുപ്പമാക്കുകയും ക്ലയന്റ് ആപ്ലിക്കേഷനെ ശരിയായ പാതയിലേക്ക് നയിക്കുകയും ചെയ്യുന്ന ഒരു ശക്തമായ ഉപകരണമാണ്. ഈ സന്ദർഭത്തിൽ "പിശക്" എന്ന വാക്ക് പൂർണ്ണമായും ഉചിതമല്ല. ഇവിടെ ഒരു നല്ല വാക്ക് ആയിരിക്കും ഒഴിവാക്കൽ, വാസ്തവത്തിൽ അഭ്യർത്ഥന വിജയകരമായി സ്വീകരിക്കുകയും പാഴ്‌സ് ചെയ്യുകയും അഭ്യർത്ഥന പൂർത്തിയാക്കാൻ കഴിയാത്തത് എന്തുകൊണ്ടെന്ന് വിശദീകരിക്കുന്ന മതിയായ പ്രതികരണം നൽകുകയും ചെയ്‌തതിനാൽ.

നിങ്ങൾക്ക് ലഭിക്കുന്ന ഒഴിവാക്കലുകൾക്കുള്ള സാധ്യതയുള്ള കാരണങ്ങൾ എന്തൊക്കെയാണ്?

500 ആന്തരിക സെർവർ പിശക് - എല്ലാം തകർന്നു, പക്ഷേ ഞങ്ങൾ അത് ഉടൻ പരിഹരിക്കും

സെർവറിന്റെ വശത്ത് തന്നെ പ്രശ്‌നം സംഭവിച്ചപ്പോൾ ഇത് കൃത്യമായി സംഭവിക്കുന്നു, കൂടാതെ ക്ലയന്റ് ആപ്ലിക്കേഷന് നെടുവീർപ്പിടാനും സെർവർ ക്ഷീണിതനാണെന്നും വിശ്രമിക്കാൻ കിടക്കുകയാണെന്നും ഉപയോക്താവിനെ അറിയിക്കാനും മാത്രമേ കഴിയൂ. ഉദാഹരണത്തിന്, ഡാറ്റാബേസിലേക്കുള്ള കണക്ഷൻ നഷ്ടപ്പെട്ടു അല്ലെങ്കിൽ കോഡിൽ ഒരു ബഗ് ഉണ്ട്.

400 മോശം അഭ്യർത്ഥന - ഇപ്പോൾ നിങ്ങൾക്കായി എല്ലാം തകർന്നിരിക്കുന്നു

ഉത്തരം മുമ്പത്തേതിന് വിപരീതമാണ്. തത്ത്വത്തിൽ, ശരിയായി പ്രോസസ്സ് ചെയ്യാൻ കഴിയാത്ത, ആവശ്യമായ പാരാമീറ്ററുകൾ അടങ്ങിയിട്ടില്ലാത്ത, അല്ലെങ്കിൽ വാക്യഘടന പിശകുകളുള്ള ഒരു അഭ്യർത്ഥന ക്ലയന്റ് ആപ്ലിക്കേഷൻ അയയ്ക്കുന്ന സന്ദർഭങ്ങളിൽ തിരികെ നൽകി. വെബ് API ഡോക്യുമെന്റേഷൻ വീണ്ടും വായിക്കുന്നതിലൂടെ ഇത് സാധാരണയായി പരിഹരിക്കാവുന്നതാണ്.

401 അനധികൃത - അപരിചിതൻ, സ്വയം തിരിച്ചറിയുക

ഈ റിസോഴ്സ് ആക്സസ് ചെയ്യുന്നതിന് അംഗീകാരം ആവശ്യമാണ്. തീർച്ചയായും, അംഗീകാരം ലഭിക്കുന്നത് ഉറവിടം ലഭ്യമാകുമെന്ന് ഉറപ്പുനൽകുന്നില്ല, എന്നാൽ അംഗീകാരമില്ലാതെ, നിങ്ങൾക്ക് തീർച്ചയായും അറിയാൻ കഴിയില്ല. ഉദാഹരണത്തിന്, API-യുടെ ഒരു സ്വകാര്യ ഭാഗം ആക്‌സസ് ചെയ്യാൻ ശ്രമിക്കുമ്പോഴോ നിലവിലെ ടോക്കൺ കാലഹരണപ്പെടുമ്പോഴോ സംഭവിക്കുന്നു.

403 നിരോധിച്ചിരിക്കുന്നു - നിങ്ങൾക്ക് ഇവിടെ അനുവദനീയമല്ല

അഭ്യർത്ഥിച്ച ഉറവിടം നിലവിലുണ്ട്, പക്ഷേ ഉപയോക്താവിന് അത് കാണാനോ പരിഷ്ക്കരിക്കാനോ മതിയായ അവകാശങ്ങളില്ല.

404 കണ്ടെത്തിയില്ല - ഈ വിലാസത്തിൽ ആരും താമസിക്കുന്നില്ല

അത്തരമൊരു പ്രതികരണം ഒരു ചട്ടം പോലെ, മൂന്ന് കേസുകളിൽ തിരികെ നൽകുന്നു: ഉറവിടത്തിലേക്കുള്ള പാത തെറ്റാണ് (തെറ്റായത്), അഭ്യർത്ഥിച്ച ഉറവിടം ഇല്ലാതാക്കി നിലവിലില്ല, നിലവിലെ ഉപയോക്താവിന്റെ അവകാശങ്ങൾ അസ്തിത്വത്തെക്കുറിച്ച് അറിയാൻ അവനെ അനുവദിക്കുന്നില്ല. ആവശ്യപ്പെട്ട വിഭവത്തിന്റെ. ഉദാഹരണത്തിന്, ഞങ്ങൾ ഉൽപ്പന്നങ്ങളുടെ ഒരു ലിസ്‌റ്റ് നോക്കുമ്പോൾ, അവയിലൊന്ന് പെട്ടെന്ന് സ്‌റ്റൈൽ ഇല്ലാതാകുകയും നീക്കം ചെയ്യുകയും ചെയ്തു.

405 രീതി അനുവദനീയമല്ല - നിങ്ങൾക്ക് ഇത് ചെയ്യാൻ കഴിയില്ല

ഇത്തരത്തിലുള്ള ഒഴിവാക്കലുകൾ അഭ്യർത്ഥനയിൽ (GET, PUT, POST, DELETE) ഉപയോഗിച്ചിരിക്കുന്ന ക്രിയയുമായി നേരിട്ട് ബന്ധപ്പെട്ടിരിക്കുന്നു, ഇത് റിസോഴ്സ് ഉപയോഗിച്ച് ഞങ്ങൾ ചെയ്യാൻ ശ്രമിക്കുന്ന പ്രവർത്തനത്തെ സൂചിപ്പിക്കുന്നു. അഭ്യർത്ഥിച്ച ഉറവിടം നിർദ്ദിഷ്ട പ്രവർത്തനത്തെ പിന്തുണയ്ക്കുന്നില്ലെങ്കിൽ, സെർവർ അത് വ്യക്തമായി പറയുന്നു.

422 പ്രോസസ്സ് ചെയ്യാനാവാത്ത എന്റിറ്റി - ശരിയാക്കി വീണ്ടും അയയ്ക്കുക

ഏറ്റവും ഉപയോഗപ്രദമായ ഒഴിവാക്കലുകളിൽ ഒന്ന്. അഭ്യർത്ഥന ഡാറ്റയിൽ ലോജിക്കൽ പിശകുകൾ ഉണ്ടാകുമ്പോഴെല്ലാം തിരികെ നൽകും. അഭ്യർത്ഥന ഡാറ്റ എന്നതുകൊണ്ട് ഞങ്ങൾ അർത്ഥമാക്കുന്നത് ഒന്നുകിൽ GET രീതി പാസാക്കിയ ഒരു കൂട്ടം പാരാമീറ്ററുകളും അവയുടെ അനുബന്ധ മൂല്യങ്ങളും അല്ലെങ്കിൽ POST, PUT, DELETE രീതികൾ വഴി അഭ്യർത്ഥനയുടെ ബോഡിയിൽ പാസാക്കിയ ഒരു വസ്തുവിന്റെ ഫീൽഡുകൾ. ഡാറ്റ സാധൂകരിച്ചിട്ടില്ലെങ്കിൽ, ഏത് പാരാമീറ്ററുകൾ അസാധുവാണെന്നും എന്തുകൊണ്ടാണെന്നും “ഡാറ്റ” വിഭാഗത്തിൽ സെർവർ ഒരു റിപ്പോർട്ട് നൽകുന്നു.

HTTP പ്രോട്ടോക്കോൾ എല്ലാ അവസരങ്ങളിലും വ്യത്യസ്ത സ്റ്റാറ്റസ് കോഡുകളുടെ ഒരു വലിയ സംഖ്യയെ പിന്തുണയ്ക്കുന്നു, എന്നാൽ പ്രായോഗികമായി അവ വളരെ അപൂർവമായി മാത്രമേ ഉപയോഗിക്കുന്നുള്ളൂ, കൂടാതെ ഒരു വെബ് API യുടെ പശ്ചാത്തലത്തിൽ പ്രായോഗികമായ ഉപയോഗമില്ല. എന്റെ ഓർമ്മയിൽ, മേൽപ്പറഞ്ഞ ഒഴിവാക്കലുകളുടെ പട്ടികയ്ക്ക് അപ്പുറത്തേക്ക് പോകേണ്ടി വന്നിട്ടില്ല.

അഭ്യർത്ഥനകൾ

ശേഖരണ ഇനങ്ങൾ വീണ്ടെടുക്കുന്നു

ഏറ്റവും സാധാരണമായ അഭ്യർത്ഥനകളിലൊന്ന് ശേഖരണ ഘടകങ്ങൾ നേടാനുള്ള അഭ്യർത്ഥനയാണ്. ക്ലയന്റ് ആപ്ലിക്കേഷൻ വിവര ഫീഡുകൾ, ഉൽപ്പന്ന ലിസ്റ്റുകൾ, വിവിധ വിവരങ്ങൾ, സ്റ്റാറ്റിസ്റ്റിക്കൽ ടേബിളുകൾ എന്നിവയും അതിലേറെയും ശേഖരണ ഉറവിടങ്ങൾ ആക്സസ് ചെയ്യുന്നതിലൂടെ പ്രദർശിപ്പിക്കുന്നു. ഈ അഭ്യർത്ഥന നടത്താൻ, ഞങ്ങൾ GET രീതി ഉപയോഗിച്ച് ശേഖരം ആക്‌സസ് ചെയ്യുകയും അന്വേഷണ സ്‌ട്രിംഗിൽ അധിക പാരാമീറ്ററുകൾ കൈമാറുകയും ചെയ്യുന്നു. ഞങ്ങൾ ഇതിനകം മുകളിൽ സൂചിപ്പിച്ചതുപോലെ, ഒരു പ്രതികരണമെന്ന നിലയിൽ ഏകതാനമായ ശേഖരണ ഘടകങ്ങളുടെ ഒരു നിരയും പേജിനേഷന് ആവശ്യമായ വിവരങ്ങളും ലഭിക്കുമെന്ന് ഞങ്ങൾ പ്രതീക്ഷിക്കുന്നു - ലിസ്റ്റിന്റെ തുടർച്ച അല്ലെങ്കിൽ അതിന്റെ നിർദ്ദിഷ്ട പേജ് ലോഡ് ചെയ്യുന്നു. അധിക പാരാമീറ്ററുകൾ പാസാക്കുന്നതിലൂടെ തിരഞ്ഞെടുക്കലിന്റെ ഉള്ളടക്കങ്ങൾ പരിമിതപ്പെടുത്താനും പ്രത്യേക രീതിയിൽ അടുക്കാനും കഴിയും. അവ കൂടുതൽ ചർച്ച ചെയ്യും.

പേജ് നാവിഗേഷൻ

പേജ്- ഏത് പേജാണ് പ്രദർശിപ്പിക്കേണ്ടതെന്ന് പരാമീറ്റർ സൂചിപ്പിക്കുന്നു. ഈ പരാമീറ്റർ പാസ്സാക്കിയില്ലെങ്കിൽ, ആദ്യ പേജ് പ്രദർശിപ്പിക്കും. സെർവറിൽ നിന്നുള്ള ആദ്യ വിജയകരമായ പ്രതികരണത്തിൽ നിന്ന്, നിലവിലെ ഫിൽട്ടറിംഗ് പാരാമീറ്ററുകൾ ഉപയോഗിച്ച് ശേഖരത്തിന് എത്ര പേജുകൾ ഉണ്ടെന്ന് വ്യക്തമാകും. മൂല്യം പരമാവധി പേജുകളുടെ എണ്ണം കവിയുന്നുവെങ്കിൽ, ഒരു പിശക് നൽകുന്നതാണ് നല്ലത് 404 കണ്ടെത്തിയില്ല.

GET /api/v1/news?page=1

ഓരോ പേജ്- പേജിൽ ആവശ്യമുള്ള ഘടകങ്ങളുടെ എണ്ണം സൂചിപ്പിക്കുന്നു. സാധാരണഗതിയിൽ, API-ക്ക് അതിന്റേതായ സ്ഥിരസ്ഥിതി മൂല്യമുണ്ട്, അത് പേജിനേഷൻ വിഭാഗത്തിലെ പെർപേജ് ഫീൽഡായി നൽകുന്നു, എന്നാൽ ചില സന്ദർഭങ്ങളിൽ maxPerPage-ന്റെ പരമാവധി മൂല്യം നൽകിക്കൊണ്ട് ഈ മൂല്യം ന്യായമായ പരിധിയിലേക്ക് വർദ്ധിപ്പിക്കാൻ ഇത് നിങ്ങളെ അനുവദിക്കുന്നു:

GET /api/v1/news?perPage=100

ഫലങ്ങൾ അടുക്കുന്നു

പലപ്പോഴും, താരതമ്യ (സംഖ്യാ ഫീൽഡുകൾക്ക്) അല്ലെങ്കിൽ അക്ഷരമാലാക്രമത്തിൽ (സ്ട്രിംഗ് ഫീൽഡുകൾക്ക്) സോർട്ടിംഗിനെ പിന്തുണയ്ക്കുന്ന ചില ഫീൽഡുകളുടെ ആരോഹണ അല്ലെങ്കിൽ അവരോഹണ മൂല്യങ്ങൾ ഉപയോഗിച്ച് ഒരു തിരഞ്ഞെടുപ്പിന്റെ ഫലങ്ങൾ അടുക്കാൻ നിങ്ങൾ ആഗ്രഹിക്കുന്നു. ഉദാഹരണത്തിന്, ഞങ്ങൾ ഉപയോക്താക്കളുടെ ഒരു ലിസ്റ്റ് പേര് അല്ലെങ്കിൽ ഉൽപ്പന്നങ്ങൾ വില പ്രകാരം സംഘടിപ്പിക്കേണ്ടതുണ്ട്. കൂടാതെ, നമുക്ക് സോർട്ടിംഗ് ദിശ A മുതൽ Z വരെ അല്ലെങ്കിൽ വിപരീത ദിശയിൽ സജ്ജീകരിക്കാം, വ്യത്യസ്ത ഫീൽഡുകൾക്ക് ഇത് വ്യത്യസ്തമാണ്.

ഇങ്ങനെ അടുക്കുക- GET പാരാമീറ്ററുകളിൽ സങ്കീർണ്ണമായ സോർട്ടിംഗ് ഡാറ്റ കൈമാറുന്നതിന് നിരവധി സമീപനങ്ങളുണ്ട്. ഇവിടെ ക്രമപ്പെടുത്തൽ ക്രമവും ദിശയും വ്യക്തമായി സൂചിപ്പിക്കേണ്ടത് ആവശ്യമാണ്.

ചില API-കൾ ഇത് ഒരു സ്ട്രിംഗ് ആയി ചെയ്യാൻ നിർദ്ദേശിക്കുന്നു:

GET /api/v1/products?sortBy=name.desc,price.asc

മറ്റ് ഓപ്ഷനുകൾ ഒരു അറേ ഉപയോഗിക്കാൻ നിർദ്ദേശിക്കുന്നു:

/api/v1/products നേടണോ? sortBy=name& sortBy=desc& sortBy=price& sortBy=asc

പൊതുവേ, രണ്ട് ഓപ്ഷനുകളും തുല്യമാണ്, കാരണം അവ ഒരേ നിർദ്ദേശങ്ങൾ നൽകുന്നു. എന്റെ അഭിപ്രായത്തിൽ, ഒരു അറേ ഉള്ള ഓപ്ഷൻ കൂടുതൽ സാർവത്രികമാണ്, പക്ഷേ, അവർ പറയുന്നതുപോലെ, അത് രുചിയെയും നിറത്തെയും ആശ്രയിച്ചിരിക്കുന്നു ...

മൂല്യം അനുസരിച്ച് ലളിതമായ ഫിൽട്ടറിംഗ്

ഒരു ഫീൽഡിന്റെ മൂല്യം അനുസരിച്ച് ഒരു തിരഞ്ഞെടുപ്പ് ഫിൽട്ടർ ചെയ്യുന്നതിന്, മിക്ക കേസുകളിലും ഫീൽഡ് നാമവും ആവശ്യമായ മൂല്യവും ഒരു ഫിൽട്ടർ പാരാമീറ്ററായി നൽകിയാൽ മതിയാകും. ഉദാഹരണത്തിന്, രചയിതാവ് ഐഡി പ്രകാരം ലേഖനങ്ങൾ ഫിൽട്ടർ ചെയ്യാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു:

GET /api/v1/articles?authorId=25

വിപുലമായ ഫിൽട്ടറിംഗ് ഓപ്ഷനുകൾ

പല ഇന്റർഫേസുകൾക്കും കൂടുതൽ സങ്കീർണ്ണമായ ഫിൽട്ടറിംഗ്, സെർച്ചിംഗ് സിസ്റ്റങ്ങൾ ആവശ്യമാണ്. പ്രധാനവും ഏറ്റവും സാധാരണവുമായ ഫിൽട്ടറിംഗ് ഓപ്ഷനുകൾ ഞാൻ ലിസ്റ്റ് ചെയ്യും.

(കൂടുതൽ അല്ലെങ്കിൽ തുല്യമായത്), ഉയർന്നത് (അതിനേക്കാൾ വലുത്), (കുറവ് അല്ലെങ്കിൽ തുല്യം), താഴെ (കുറവ്) എന്നിവയിൽ നിന്ന് താരതമ്യ ഓപ്പറേറ്റർമാർ ഉപയോഗിച്ച് മുകളിലും താഴെയുമുള്ള അതിരുകൾ ഉപയോഗിച്ച് ഫിൽട്ടർ ചെയ്യുന്നു. മൂല്യങ്ങൾ റാങ്ക് ചെയ്യാൻ കഴിയുന്ന ഫീൽഡുകൾക്ക് ബാധകമാണ്.

GET /api/v1/products?price=500&price=1000

ലിസ്റ്റിൽ നിന്ന് സാധ്യമായ നിരവധി മൂല്യങ്ങൾ ഉപയോഗിച്ച് ഫിൽട്ടർ ചെയ്യുക. സാധ്യമായ മൂല്യങ്ങളുടെ സെറ്റ് പരിമിതമായ ഫീൽഡുകൾക്ക് ബാധകമാണ്, ഉദാഹരണത്തിന്, നിരവധി സ്റ്റാറ്റസുകളുള്ള ഒരു ഫിൽട്ടർ:

GET /api/v1/products?status=1&status=2

ഭാഗിക സ്ട്രിംഗ് പൊരുത്തം പ്രകാരം ഫിൽട്ടർ ചെയ്യുന്നു. സംഖ്യാ ഉൽപ്പന്ന SKU-കൾ, ഫോൺ നമ്പറുകൾ മുതലായവ പോലുള്ള ടെക്‌സ്‌റ്റ് ഡാറ്റയോ ടെക്‌സ്‌റ്റിനോട് തുല്യമാക്കാവുന്ന ഡാറ്റയോ അടങ്ങിയ ഫീൽഡുകൾക്ക് ബാധകമാണ്.

GET /api/v1/users?name=John GET /api/v1/products?code=123

പേരുള്ള ഫിൽട്ടറുകൾ

ചില സാഹചര്യങ്ങളിൽ, ചില സെറ്റ് ഫിൽട്ടർ പാരാമീറ്ററുകൾ പലപ്പോഴും ഉപയോഗിക്കുകയും സിസ്റ്റം സമഗ്രമായി സൂചിപ്പിക്കുകയും ചെയ്യുമ്പോൾ, പ്രത്യേകിച്ചും അവ ആന്തരികവും പലപ്പോഴും സങ്കീർണ്ണവുമായ സാമ്പിൾ മെക്കാനിക്കുകളെ ബാധിക്കുകയാണെങ്കിൽ, അവയെ പേരുള്ള ഫിൽട്ടറുകൾ എന്ന് വിളിക്കുന്നത് ഉചിതമാണ്. അഭ്യർത്ഥനയിൽ ഫിൽട്ടർ നാമം പാസ്സാക്കിയാൽ മതി, സിസ്റ്റം സ്വയം തിരഞ്ഞെടുക്കൽ നിർമ്മിക്കും.

GET /api/v1/products?filters=recommended

പേരിട്ടിരിക്കുന്ന ഫിൽട്ടറുകൾക്ക് അവരുടേതായ പാരാമീറ്ററുകളും ഉണ്ടായിരിക്കാം.

GET /api/v1/products?filters=kids

ഈ ഉപവിഭാഗത്തിൽ, ആവശ്യമായ സാമ്പിൾ നേടുന്നതിനുള്ള ഏറ്റവും ജനപ്രിയമായ ഓപ്ഷനുകളെയും രീതികളെയും കുറിച്ച് സംസാരിക്കാൻ ഞാൻ ശ്രമിച്ചു. മിക്കവാറും, നിങ്ങളുടെ പരിശീലനത്തിൽ ഈ വിഷയവുമായി ബന്ധപ്പെട്ട് നിരവധി ഉദാഹരണങ്ങളും സൂക്ഷ്മതകളും ഉണ്ടാകും. നിങ്ങൾക്ക് എന്റെ മെറ്റീരിയലിൽ എന്തെങ്കിലും ചേർക്കാനുണ്ടെങ്കിൽ, ഞാൻ സന്തോഷിക്കും. ഇതിനിടയിൽ, പോസ്റ്റ് ഇതിനകം തന്നെ ഗണ്യമായ സ്കെയിലിലേക്ക് വളർന്നു, അതിനാൽ അടുത്ത ഏകദേശത്തിൽ ഞങ്ങൾ മറ്റ് തരത്തിലുള്ള അഭ്യർത്ഥനകൾ വിശകലനം ചെയ്യും.

FILE SERVER സാങ്കേതികവിദ്യ ഉപയോഗിച്ച് പ്രവർത്തിക്കുന്ന DB-കൾ;

CLIENT-SERVER സാങ്കേതികവിദ്യ ഉപയോഗിച്ച് പ്രവർത്തിക്കുന്ന DB-കൾ.

ഫയൽ സെർവർ

- ഡാറ്റാബേസിലേക്കുള്ള ആക്സസ് (ചോദ്യം)
- മറ്റ് ഉപയോക്താക്കൾക്കുള്ള ആക്സസ് തടയുമ്പോൾ ഡാറ്റ കൈമാറുന്നു
- ഉപയോക്താവിന്റെ കമ്പ്യൂട്ടറിൽ ഡാറ്റ പ്രോസസ്സിംഗ്

വ്യക്തതയ്ക്കായി, നമുക്ക് നിർദ്ദിഷ്ട ഉദാഹരണങ്ങൾ നോക്കാം. മെയ് 19 മുതൽ മെയ് 25 വരെയുള്ള കാലയളവിൽ 5,000 റൂബിൾ തുകയിൽ അയച്ച പേയ്‌മെന്റ് ഓർഡറുകൾ നിങ്ങൾ കാണേണ്ടതുണ്ടെന്ന് നമുക്ക് പറയാം. പേയ്‌മെന്റ് ഓർഡറുകൾക്കൊപ്പം ഡാറ്റാബേസിൽ പ്രവർത്തിക്കുന്ന ഒരു ക്ലയന്റ് ആപ്ലിക്കേഷൻ ഉപയോക്താവിന് തന്റെ കമ്പ്യൂട്ടറിൽ സമാരംഭിക്കുകയും ആവശ്യമായ തിരഞ്ഞെടുക്കൽ മാനദണ്ഡം നൽകുകയും വേണം. അതിനുശേഷം, ഈ തരത്തിലുള്ള എല്ലാ രേഖകളും ഉൾക്കൊള്ളുന്ന ഒരു ഫയൽ, ഡാറ്റാബേസ് സെർവറിൽ നിന്ന് നിങ്ങളുടെ കമ്പ്യൂട്ടറിലേക്ക് ഡൗൺലോഡ് ചെയ്യുകയും റാമിലേക്ക് ലോഡ് ചെയ്യുകയും ചെയ്യും. ഡാറ്റാബേസിനൊപ്പം പ്രവർത്തിക്കുന്ന ഉപയോക്താവിന്റെ കമ്പ്യൂട്ടറിൽ പ്രവർത്തിക്കുന്ന ഒരു ക്ലയന്റ് ആപ്ലിക്കേഷൻ ഈ വിവരങ്ങൾ പ്രോസസ്സ് ചെയ്യും (അത് അടുക്കുക) തുടർന്ന് ഒരു പ്രതികരണം നൽകും (നിങ്ങളുടെ മാനദണ്ഡങ്ങൾ പാലിക്കുന്ന പേയ്‌മെന്റ് ഓർഡറുകളുടെ ഒരു ലിസ്റ്റ് സ്ക്രീനിൽ ദൃശ്യമാകും). ഇതിനുശേഷം, നിങ്ങൾ ആവശ്യമുള്ള പേയ്‌മെന്റ് ഓർഡർ തിരഞ്ഞെടുത്ത് അതിൽ ഒരു ഫീൽഡ് എഡിറ്റുചെയ്യാൻ (മാറ്റാൻ) ശ്രമിക്കും - ഉദാഹരണത്തിന്, തീയതി. എഡിറ്റിംഗ് സമയത്ത്, ഡാറ്റ ഉറവിടം തടഞ്ഞു, അതായത്, ഈ പ്രമാണം അടങ്ങിയിരിക്കുന്ന മുഴുവൻ ഫയലും. ഇതിനർത്ഥം ഫയൽ മറ്റ് ഉപയോക്താക്കൾക്ക് ലഭ്യമാകില്ല, അല്ലെങ്കിൽ വ്യൂ മോഡിൽ മാത്രമേ ലഭ്യമാകൂ എന്നാണ്. മാത്രമല്ല, ഇത്തരത്തിലുള്ള ക്യാപ്‌ചർ റെക്കോർഡ് തലത്തിൽ പോലും സംഭവിക്കുന്നില്ല, അതായത് ഒരു പ്രമാണം, പക്ഷേ മുഴുവൻ ഫയലും ലോക്ക് ചെയ്‌തിരിക്കുന്നു - അതായത്, സമാന പ്രമാണങ്ങൾ അടങ്ങിയ മുഴുവൻ പട്ടികയും. ഈ ഫീൽഡ് പൂർണ്ണമായി പ്രോസസ്സ് ചെയ്‌ത് എഡിറ്റിംഗ് മോഡിൽ നിന്ന് പുറത്തുകടന്നതിനുശേഷം മാത്രമേ, ഈ പേയ്‌മെന്റ് ഓർഡർ ഫയൽ ഉപയോക്താവ് ക്യാപ്‌ചർ ചെയ്യുന്നതിൽ നിന്ന് അൺലോക്ക് ചെയ്യുകയുള്ളൂ. ഡാറ്റ വലിയ ഒബ്‌ജക്‌റ്റുകളിൽ സംഭരിച്ചിട്ടുണ്ടെങ്കിൽ, ഉദാഹരണത്തിന്, ഒരു ഫയലിൽ ഫണ്ടുകളുടെ രസീതിനും ഫണ്ടുകൾ അയയ്‌ക്കുന്നതിനുമുള്ള പേയ്‌മെന്റ് ഓർഡറുകൾ അടങ്ങിയിരിക്കുന്നു, തുടർന്ന് കൂടുതൽ വിവരങ്ങൾ ലഭ്യമാകില്ല. നിങ്ങൾ ഒരു ഡോക്യുമെന്റിൽ ഒരു "തീയതി" ഫീൽഡിൽ പ്രവർത്തിക്കും - ബാക്കിയുള്ള എന്റർപ്രൈസ് ജീവനക്കാർ നിങ്ങൾ പൂർത്തിയാക്കുന്നത് വരെ കാത്തിരിക്കും.

FILE സെർവർ സിസ്റ്റത്തിന്റെ പോരായ്മകൾ വ്യക്തമാണ്:

നെറ്റ്വർക്കിൽ വളരെ ഉയർന്ന ലോഡ്, വർദ്ധിച്ച ബാൻഡ്വിഡ്ത്ത് ആവശ്യകതകൾ. പ്രായോഗികമായി, ഇത് ഒരു വലിയ അളവിലുള്ള ഉപയോക്താക്കൾക്ക് ഒരേസമയം വലിയ അളവിലുള്ള ഡാറ്റ ഉപയോഗിച്ച് പ്രവർത്തിക്കുന്നത് മിക്കവാറും അസാധ്യമാക്കുന്നു.

ഉപയോക്താക്കളുടെ കമ്പ്യൂട്ടറിൽ ഡാറ്റ പ്രോസസ്സിംഗ് നടത്തുന്നു. ഇത് ഓരോ ഉപയോക്താവിനും വർദ്ധിച്ച ഹാർഡ്‌വെയർ ആവശ്യകതകൾ ഉൾക്കൊള്ളുന്നു. കൂടുതൽ ഉപയോക്താക്കൾ ഉള്ളതിനാൽ, അവരുടെ കമ്പ്യൂട്ടറുകൾ സജ്ജീകരിക്കുന്നതിന് നിങ്ങൾ കൂടുതൽ പണം ചെലവഴിക്കേണ്ടിവരും.

ഒരു ഉപയോക്താവ് എഡിറ്റ് ചെയ്യുമ്പോൾ ഡാറ്റ ലോക്ക് ചെയ്യുന്നത് മറ്റ് ഉപയോക്താക്കൾക്ക് ഈ ഡാറ്റ ഉപയോഗിച്ച് പ്രവർത്തിക്കുന്നത് അസാധ്യമാക്കുന്നു.

സുരക്ഷ. അത്തരമൊരു സിസ്റ്റത്തിൽ പ്രവർത്തിക്കാൻ, നിങ്ങൾ ഓരോ ഉപയോക്താവിനും മുഴുവൻ ഫയലിലേക്കും പൂർണ്ണ ആക്സസ് നൽകേണ്ടതുണ്ട്, അതിൽ അയാൾക്ക് ഒരു ഫീൽഡിൽ മാത്രം താൽപ്പര്യമുണ്ടാകാം.

ക്ലയന്റ്-സെർവർ

ഒരൊറ്റ ഉപയോക്തൃ അഭ്യർത്ഥന പ്രോസസ്സ് ചെയ്യുന്നു:
- ഡാറ്റാബേസിലേക്കുള്ള ആക്സസ് (SQL അന്വേഷണം)
- പ്രതികരണത്തിന്റെ സംപ്രേക്ഷണം - പ്രോസസ്സിംഗിന്റെ ഫലം




ഡാറ്റാബേസിൽ സംഭരിച്ചിരിക്കുന്ന വിവരങ്ങൾ പ്രോസസ്സ് ചെയ്യേണ്ടത് ആവശ്യമാണെങ്കിൽ, ഡാറ്റാബേസിനൊപ്പം പ്രവർത്തിക്കുന്ന ഉപയോക്താവിന്റെ കമ്പ്യൂട്ടറിൽ പ്രവർത്തിക്കുന്ന ഒരു ക്ലയന്റ് ആപ്ലിക്കേഷൻ SQL ഭാഷയിൽ ഒരു ചോദ്യം സൃഷ്ടിക്കുന്നു (പ്രാരംഭ അക്ഷരങ്ങളിൽ നിന്നുള്ള പേര് - ഘടനാപരമായ അന്വേഷണ ഭാഷ). ഡാറ്റാബേസ് സെർവർ അഭ്യർത്ഥന സ്വീകരിക്കുകയും സ്വതന്ത്രമായി പ്രോസസ്സ് ചെയ്യുകയും ചെയ്യുന്നു. നെറ്റ്‌വർക്കിലൂടെ ഒരു ഡാറ്റ അറേയും (ഫയൽ) കൈമാറ്റം ചെയ്യപ്പെടുന്നില്ല. അഭ്യർത്ഥന പ്രോസസ്സ് ചെയ്ത ശേഷം, ഫലം മാത്രമേ ഉപയോക്താവിന്റെ കമ്പ്യൂട്ടറിലേക്ക് കൈമാറുകയുള്ളൂ - അതായത്, മുമ്പത്തെ ഉദാഹരണത്തിൽ, ആവശ്യമായ മാനദണ്ഡങ്ങൾ പാലിക്കുന്ന പേയ്മെന്റ് ഓർഡറുകളുടെ ഒരു ലിസ്റ്റ്. പ്രോസസ്സിംഗിനുള്ള ഉറവിടമായി സേവിച്ച ഡാറ്റ സംഭരിച്ച ഫയൽ തന്നെ, മറ്റ് ഉപയോക്താക്കളുടെ അഭ്യർത്ഥനപ്രകാരം സെർവർ തന്നെ ആക്‌സസ് ചെയ്യുന്നതിനായി അൺബ്ലോക്ക് ചെയ്‌തിരിക്കുന്നു.

ഗുരുതരമായ ക്ലയന്റ്-സെർവർ ഡിബിഎംഎസുകളിൽ, നെറ്റ്‌വർക്കിലെ ലോഡ് കുറയ്ക്കുകയും ഉപയോക്തൃ കമ്പ്യൂട്ടറുകളുടെ ആവശ്യകതകൾ കുറയ്ക്കുകയും ചെയ്യുന്ന അധിക സംവിധാനങ്ങളുണ്ട്. ഒരു ഉദാഹരണമായി, ഞങ്ങൾ സംഭരിച്ച നടപടിക്രമങ്ങൾ നൽകും - അതായത്, ഡാറ്റാബേസിൽ സംഭരിച്ചിരിക്കുന്ന ഡാറ്റ പ്രോസസ്സ് ചെയ്യുന്നതിനുള്ള മുഴുവൻ പ്രോഗ്രാമുകളും. ഈ സാഹചര്യത്തിൽ, SQL എക്സ്പ്രഷനുകൾ പോലും ഉപയോക്താവിൽ നിന്ന് സെർവറിലേക്ക് മാറ്റില്ല - കോൾ പാരാമീറ്ററുകളുള്ള ഒരു ഫംഗ്ഷൻ കോൾ കൈമാറ്റം ചെയ്യപ്പെടുന്നു. അങ്ങനെ, ഉപയോക്താവിന്റെ ജോലിസ്ഥലം കൂടുതൽ ലളിതമാക്കി, പ്രോഗ്രാമിന്റെ യുക്തി സെർവറിലേക്ക് മാറ്റുന്നു. ഉപയോക്തൃ ഇടം വിവരങ്ങൾ പ്രദർശിപ്പിക്കുന്നതിനുള്ള ഒരു ഉപാധിയായി മാറുന്നു. ഇതെല്ലാം അർത്ഥമാക്കുന്നത് നെറ്റ്‌വർക്കിലെയും ഉപയോക്തൃ വർക്ക്‌സ്റ്റേഷനുകളിലെയും ലോഡിൽ കൂടുതൽ കുറയ്ക്കൽ എന്നാണ്.

അതിനാൽ, FILE-SERVER സ്കീമിന്റെ മുകളിലുള്ള എല്ലാ ദോഷങ്ങളും ക്ലയന്റ്-സെർവർ ആർക്കിടെക്ചറിൽ ഇല്ലാതാക്കുന്നു:

ഡാറ്റാബേസ് സെർവറിൽ നിന്ന് ഉപയോക്താവിന്റെ കമ്പ്യൂട്ടറിലേക്ക് നെറ്റ്‌വർക്കിലൂടെ ഡാറ്റ അറേകൾ കൈമാറ്റം ചെയ്യപ്പെടുന്നില്ല. നെറ്റ്‌വർക്ക് ബാൻഡ്‌വിഡ്ത്ത് ആവശ്യകതകൾ കുറയുന്നു. വലിയ അളവിലുള്ള ഡാറ്റ ഉപയോഗിച്ച് ഒരേസമയം പ്രവർത്തിക്കാൻ ഇത് ധാരാളം ഉപയോക്താക്കൾക്ക് സാധ്യമാക്കുന്നു.

ഡാറ്റാ പ്രോസസ്സിംഗ് നടത്തുന്നത് ഡാറ്റാബേസ് സെർവറിലാണ്, അല്ലാതെ ഉപയോക്താക്കളുടെ കമ്പ്യൂട്ടറിലല്ല. ക്ലയന്റ് സൈറ്റുകളിൽ ലളിതവും അതിനാൽ വിലകുറഞ്ഞതുമായ കമ്പ്യൂട്ടറുകൾ ഉപയോഗിക്കാൻ ഇത് അനുവദിക്കുന്നു.

ഒരു ഉപയോക്താവ് ഡാറ്റ തടഞ്ഞിട്ടില്ല (പിടിച്ചെടുക്കുന്നു).

ഉപയോക്താവിന് ആക്‌സസ് നൽകിയിരിക്കുന്നത് മുഴുവൻ ഫയലിലേക്കല്ല, മറിച്ച് ഉപയോക്താവിന് പ്രവർത്തിക്കാൻ അവകാശമുള്ള ഡാറ്റയിലേക്കാണ്.

ഒരു ഫയൽ സെർവറും ഒരു ക്ലയന്റ് സെർവറും തമ്മിലുള്ള വ്യത്യാസം പരിഗണിച്ച്, "വിവര സംഭരണം" എന്ന ആശയം നമുക്ക് പരിഗണിക്കാം. കോർപ്പറേറ്റ് സിസ്റ്റത്തിന്റെ പ്രവർത്തനം പ്രധാനമായും ഉപയോഗിക്കുന്ന DBMS തരത്തെ ആശ്രയിച്ചിരിക്കുന്നു എന്നത് ഊന്നിപ്പറയേണ്ടതാണ്. വലിയ സംരംഭങ്ങൾക്ക്, ധാരാളം ഉപയോക്താക്കളുള്ള, ഡാറ്റാബേസിൽ ധാരാളം റെക്കോർഡുകളുള്ള, ഫയൽ-സെർവർ സ്കീം പൂർണ്ണമായും അസ്വീകാര്യമാണ് എന്നത് വളരെ വ്യക്തമാണ്. മറുവശത്ത്, മറ്റ് പാരാമീറ്ററുകളിലും കഴിവുകളിലും ഡാറ്റാബേസുകളിൽ വ്യത്യാസങ്ങളുണ്ട്:

ഡാറ്റാബേസിൽ സംഭരിക്കാൻ കഴിയുന്ന തരത്തിലുള്ള ഡാറ്റ (നമ്പറുകൾ, തീയതികൾ, വാചകം, ചിത്രങ്ങൾ, വീഡിയോ, ശബ്ദം മുതലായവ);

ഡാറ്റാബേസിലെ ഡാറ്റ ആക്‌സസ് ചെയ്യുന്നതിനായി ഡാറ്റാബേസ് തന്നെ സംഘടിപ്പിച്ച സാങ്കേതികവിദ്യകളിലും അനധികൃത ആക്‌സസ്സിൽ നിന്നുള്ള വിവര സംരക്ഷണ നിലവാരത്തിലും;

ഈ ഡാറ്റാബേസിനെ അടിസ്ഥാനമാക്കി ഏത് വിവര സംവിധാനവും രൂപകൽപ്പന ചെയ്യാൻ ഉപയോഗിക്കാവുന്ന, നൽകിയിരിക്കുന്ന വികസന ഉപകരണങ്ങളും രീതികളും;

ഈ ഡാറ്റാബേസിനെ അടിസ്ഥാനമാക്കി ഒരു വിവര സംവിധാനത്തിൽ പ്രയോഗിക്കാൻ കഴിയുന്ന വിവരങ്ങൾ (ഡാറ്റ) വിശകലനം ചെയ്യുന്നതിനുള്ള നൽകിയിരിക്കുന്ന ഉപകരണങ്ങളും രീതികളും;

വിശ്വാസ്യതയുടെയും സ്ഥിരതയുടെയും കാര്യത്തിൽ, അതായത് (ഏകദേശം) ഡാറ്റാബേസിലെ റെക്കോർഡുകളുടെ എണ്ണം (പൂരിപ്പിച്ച ഫീൽഡുകൾ), ഇത് ഡാറ്റാബേസിലെ വിവരങ്ങൾ ആക്സസ് ചെയ്യാനും മാറ്റാനും വിശകലനം ചെയ്യാനുമുള്ള വിശ്വസനീയവും തടസ്സമില്ലാത്തതുമായ കഴിവ് ഉറപ്പാക്കുന്നു;

വേഗത പ്രകാരം - വിവരങ്ങൾ ആക്സസ് ചെയ്യുന്നതിനും പ്രോസസ്സ് ചെയ്യുന്നതിനും ചെലവഴിച്ച സമയം;

സാധ്യമെങ്കിൽ, വ്യത്യസ്ത നിർമ്മാതാക്കളിൽ നിന്നുള്ള കമ്പ്യൂട്ടറുകളിൽ ജോലി സംഘടിപ്പിക്കുക, അതായത്, മറ്റ് പ്ലാറ്റ്ഫോമുകളുമായും ഓപ്പറേറ്റിംഗ് സിസ്റ്റങ്ങളുമായും അനുയോജ്യത;

ഡാറ്റാബേസ് ഡെവലപ്പർ അല്ലെങ്കിൽ അതിന്റെ അംഗീകൃത ഡീലർ നൽകുന്ന പിന്തുണയുടെ (സേവനം) നില പ്രകാരം;

ഈ ഡാറ്റാബേസ് ഉപയോഗിക്കുന്ന ആപ്ലിക്കേഷനുകൾ സൃഷ്ടിക്കുന്നതിനുള്ള നല്ല ടൂളുകളുടെ ലഭ്യത, മുതലായവ.

എന്തുകൊണ്ടാണ് ഇന്ന് ഒരു ഫയൽ സെർവർ സൊല്യൂഷനിൽ നിക്ഷേപിക്കുന്നത് ലാഭകരമല്ലാത്തത്? ഇന്ന്, ഡാറ്റാബേസ് വികസനത്തിന്റെ ഭാവി പാത ഇതിനകം തന്നെ വ്യക്തമാണ്. മൾട്ടി ലെവൽ ക്ലയന്റ്-സെർവർ സിസ്റ്റങ്ങൾ പ്രത്യക്ഷപ്പെടുന്നു, വളരെ നേർത്ത ക്ലയന്റുകളോടെ, ക്ലയന്റ് സ്റ്റേഷനുകളിൽ നിന്നുള്ള നിയന്ത്രണങ്ങളും പ്രകടനവും പ്ലാറ്റ്‌ഫോമും ഓപ്പറേറ്റിംഗ് സിസ്റ്റവും നീക്കം ചെയ്യുന്നു. ഒരു ക്ലയന്റ്-സെർവർ പരിഹാരത്തിന് കൂടുതൽ വികസനം വളരെ വ്യക്തമായി കാണുകയും ക്ലയന്റ്-സെർവറിൽ നിന്ന് ഒരു മൾട്ടി-ലെവൽ ക്ലയന്റ്-സെർവറിലേക്കുള്ള മാറ്റം പ്രശ്‌നകരമല്ലെങ്കിൽ, ഒരു ഫയൽ സെർവറിന് ക്ലയന്റ്-സെർവറിലേക്കുള്ള ലളിതമായ പരിവർത്തനം വളരെ വലുതാണ്. പ്രശ്‌നവും വലിയ തൊഴിൽ ചെലവും, ഇത് പെട്ടെന്ന് സാധ്യമായാൽ.

ചട്ടം പോലെ, ഒരു വിവര സംവിധാനത്തിന്റെ ഭാഗമായ കമ്പ്യൂട്ടറുകളും പ്രോഗ്രാമുകളും തുല്യമല്ല. അവരിൽ ചിലരുടെ സ്വന്തം ഉറവിടങ്ങൾ (ഫയൽ സിസ്റ്റം, പ്രൊസസർ, പ്രിന്റർ, ഡാറ്റാബേസ് മുതലായവ), മറ്റുള്ളവർക്ക് ഈ ഉറവിടങ്ങൾ ആക്സസ് ചെയ്യാനുള്ള കഴിവുണ്ട്. ഒരു റിസോഴ്‌സ് നിയന്ത്രിക്കുന്ന കമ്പ്യൂട്ടറിനെ (അല്ലെങ്കിൽ പ്രോഗ്രാം) ആ റിസോഴ്സിന്റെ സെർവർ എന്ന് വിളിക്കുന്നു (ഫയൽ സെർവർ, ഡാറ്റാബേസ് സെർവർ, കമ്പ്യൂട്ടിംഗ് സെർവർ...). ഒരു റിസോഴ്സിന്റെ ക്ലയന്റും സെർവറും ഒരേ കമ്പ്യൂട്ടർ സിസ്റ്റത്തിൽ അല്ലെങ്കിൽ ഒരു നെറ്റ്‌വർക്ക് വഴി ബന്ധിപ്പിച്ചിരിക്കുന്ന വ്യത്യസ്ത കമ്പ്യൂട്ടറുകളിൽ സ്ഥിതിചെയ്യാം.

ക്ലയന്റ്-സെർവർ സാങ്കേതികവിദ്യയുടെ അടിസ്ഥാന തത്വം ആപ്ലിക്കേഷൻ ഫംഗ്ഷനുകളെ മൂന്ന് ഗ്രൂപ്പുകളായി വിഭജിക്കുക എന്നതാണ്:

· ഡാറ്റ എൻട്രിയും ഡിസ്പ്ലേയും (ഉപയോക്തൃ ഇടപെടൽ);

· തന്നിരിക്കുന്ന വിഷയ മേഖലയ്ക്ക് പ്രത്യേകമായ പ്രയോഗിച്ച പ്രവർത്തനങ്ങൾ;

· റിസോഴ്സ് മാനേജ്മെന്റ് ഫംഗ്ഷനുകൾ (ഫയൽ സിസ്റ്റം, ഡാറ്റാബേസ് മുതലായവ)

അതിനാൽ, ഏതെങ്കിലും ആപ്ലിക്കേഷനിൽ ഇനിപ്പറയുന്ന ഘടകങ്ങൾ വേർതിരിച്ചിരിക്കുന്നു:

· ഡാറ്റാ അവതരണ ഘടകം

· ആപ്ലിക്കേഷൻ ഘടകം

· റിസോഴ്സ് മാനേജ്മെന്റ് ഘടകം

ഘടകങ്ങൾ തമ്മിലുള്ള ആശയവിനിമയം ചില നിയമങ്ങൾക്കനുസൃതമായാണ് നടത്തുന്നത്, അവയെ "ഇന്ററാക്ഷൻ പ്രോട്ടോക്കോൾ" എന്ന് വിളിക്കുന്നു.

5.1.2. ക്ലയന്റ്-സെർവർ ഇന്ററാക്ഷൻ മോഡലുകൾ

വിവരസാങ്കേതിക ഗവേഷണ മേഖലയിൽ വിദഗ്ധരായ ഗാർട്ട്നർ ഗ്രൂപ്പ്, രണ്ട്-ടയർ ക്ലയന്റ്-സെർവർ ഇന്ററാക്ഷൻ മോഡലുകളുടെ ഇനിപ്പറയുന്ന വർഗ്ഗീകരണം നിർദ്ദേശിച്ചു (ഈ മോഡലുകളെ ടു-ടയർ എന്ന് വിളിക്കുന്നു, കാരണം ആപ്ലിക്കേഷന്റെ മൂന്ന് ഘടകങ്ങൾ രണ്ട് നോഡുകൾക്കിടയിൽ വ്യത്യസ്തമായി വിതരണം ചെയ്യുന്നു. ):

ചരിത്രപരമായി, വിതരണം ചെയ്ത ഡാറ്റാ അവതരണത്തിന്റെ മാതൃകയാണ് ആദ്യം പ്രത്യക്ഷപ്പെട്ടത്, ഇത് ഒരു പൊതു ഉദ്ദേശ്യ കമ്പ്യൂട്ടറിൽ അത് ബന്ധിപ്പിച്ചിട്ടുള്ള നോൺ-ഇന്റലിജന്റ് ടെർമിനലുകളിൽ നടപ്പിലാക്കി. ഡാറ്റാ മാനേജ്മെന്റും ഉപയോക്തൃ ഇടപെടലും ഒരു പ്രോഗ്രാമിൽ സംയോജിപ്പിച്ചു; സെൻട്രൽ കമ്പ്യൂട്ടറിൽ സൃഷ്ടിച്ച "ചിത്രം" മാത്രമേ ടെർമിനലിലേക്ക് കൈമാറുകയുള്ളൂ.

തുടർന്ന്, പേഴ്സണൽ കമ്പ്യൂട്ടറുകളുടെയും (പിസി) ലോക്കൽ ഏരിയ നെറ്റ്വർക്കുകളുടെയും വരവോടെ, റിമോട്ട് ഡാറ്റാബേസ് ആക്സസ് മോഡലുകൾ നടപ്പിലാക്കി. കുറച്ചുകാലമായി, പിസി നെറ്റ്‌വർക്കുകളുടെ അടിസ്ഥാന ആർക്കിടെക്ചർ ഫയൽ സെർവർ ആർക്കിടെക്ചറായിരുന്നു. ഈ സാഹചര്യത്തിൽ, കമ്പ്യൂട്ടറുകളിലൊന്ന് ഒരു ഫയൽ സെർവറാണ്; ക്ലയന്റുകൾ ഒരു അവതരണ ഘടകവും ഒരു ആപ്ലിക്കേഷൻ ഘടകവും (ഡിബിഎംഎസും ആപ്ലിക്കേഷൻ പ്രോഗ്രാമും) സംയോജിപ്പിക്കുന്ന ആപ്ലിക്കേഷനുകൾ പ്രവർത്തിപ്പിക്കുന്നു. ഫയൽ സിസ്റ്റം പ്രവർത്തനങ്ങളിലേക്കുള്ള ലോ-ലെവൽ കോളുകളുടെ ഒരു കൂട്ടമാണ് എക്സ്ചേഞ്ച് പ്രോട്ടോക്കോൾ. ഈ വാസ്തുവിദ്യ, ഒരു ചട്ടം പോലെ, വ്യക്തിഗത ഡിബിഎംഎസുകൾ ഉപയോഗിച്ച് നടപ്പിലാക്കി, വ്യക്തമായ പോരായ്മകളുണ്ട് - ഉയർന്ന നെറ്റ്‌വർക്ക് ട്രാഫിക്കും വിഭവങ്ങളിലേക്കുള്ള ഏകീകൃത ആക്‌സസിന്റെ അഭാവവും.

ആദ്യത്തെ സ്പെഷ്യലൈസ്ഡ് ഡാറ്റാബേസ് സെർവറുകളുടെ വരവോടെ, റിമോട്ട് ഡാറ്റാബേസ് ആക്സസ് മോഡൽ വ്യത്യസ്തമായി നടപ്പിലാക്കാനുള്ള സാധ്യത സാധ്യമായി. ഈ സാഹചര്യത്തിൽ, DBMS കേർണൽ സെർവറിൽ പ്രവർത്തിക്കുന്നു, എക്സ്ചേഞ്ച് പ്രോട്ടോക്കോൾ SQL ഭാഷ ഉപയോഗിച്ചാണ് നൽകുന്നത്. ഈ സമീപനം, ഒരു ഫയൽ സെർവറുമായി താരതമ്യപ്പെടുത്തുമ്പോൾ, നെറ്റ്‌വർക്ക് ലോഡ് കുറയുന്നതിനും ക്ലയന്റ്-സെർവർ ഇന്റർഫേസിന്റെ ഏകീകരണത്തിനും കാരണമാകുന്നു. എന്നിരുന്നാലും, നെറ്റ്‌വർക്ക് ട്രാഫിക് വളരെ ഉയർന്നതാണ്, കൂടാതെ ആപ്ലിക്കേഷനുകൾ തൃപ്തികരമായി നിയന്ത്രിക്കുന്നത് ഇപ്പോഴും അസാധ്യമാണ്, കാരണം ഒരു പ്രോഗ്രാമിൽ വിവിധ ഫംഗ്ഷനുകൾ സംയോജിപ്പിച്ചിരിക്കുന്നു.

പിന്നീട്, ഒരു സജീവ സെർവർ എന്ന ആശയം വികസിപ്പിച്ചെടുത്തു, അത് സംഭരിച്ച നടപടിക്രമ സംവിധാനം ഉപയോഗിച്ചു. ആപ്ലിക്കേഷൻ ഘടകത്തിന്റെ ഒരു ഭാഗം സെർവറിലേക്ക് മാറ്റാൻ ഇത് അനുവദിച്ചു (വിതരണം ചെയ്ത ആപ്ലിക്കേഷൻ മോഡൽ). നടപടിക്രമങ്ങൾ ഒരു ഡാറ്റാബേസ് നിഘണ്ടുവിൽ സംഭരിക്കുകയും ഒന്നിലധികം ക്ലയന്റുകൾക്കിടയിൽ പങ്കിടുകയും SQL സെർവറിന്റെ അതേ കമ്പ്യൂട്ടറിൽ നടപ്പിലാക്കുകയും ചെയ്യുന്നു. ഈ സമീപനത്തിന്റെ പ്രയോജനങ്ങൾ: ആപ്ലിക്കേഷൻ ഫംഗ്‌ഷനുകളുടെ കേന്ദ്രീകൃത അഡ്മിനിസ്ട്രേഷൻ സാധ്യമാണ്, നെറ്റ്‌വർക്ക് ട്രാഫിക് ഗണ്യമായി കുറയുന്നു (എസ്‌ക്യുഎൽ അന്വേഷണങ്ങളേക്കാൾ സംഭരിച്ച നടപടിക്രമങ്ങളിലേക്കുള്ള കോളുകൾ കൈമാറുന്നതിനാൽ). പൊതു-ഉദ്ദേശ്യ ഭാഷകളെ (സി, പാസ്കൽ) അപേക്ഷിച്ച് സംഭരിച്ച നടപടിക്രമങ്ങൾ വികസിപ്പിക്കുന്നതിനുള്ള പരിമിതമായ ഉപകരണങ്ങളാണ് പോരായ്മ.

പ്രായോഗികമായി, ഒരു സമ്മിശ്ര സമീപനം ഇപ്പോൾ സാധാരണയായി ഉപയോഗിക്കുന്നു:

· സെർവറിൽ സംഭരിച്ചിരിക്കുന്ന നടപടിക്രമങ്ങൾ ഉപയോഗിച്ചാണ് ഏറ്റവും ലളിതമായ ആപ്ലിക്കേഷൻ പ്രവർത്തനങ്ങൾ നടത്തുന്നത്

· കൂടുതൽ സങ്കീർണ്ണമായ പ്രവർത്തനങ്ങൾ ആപ്ലിക്കേഷൻ പ്രോഗ്രാമിൽ നേരിട്ട് ക്ലയന്റിൽ നടപ്പിലാക്കുന്നു

നിരവധി വാണിജ്യ DBMS വെണ്ടർമാർ ജാവ ഭാഷ ഉപയോഗിച്ച് സംഭരിച്ച നടപടിക്രമങ്ങൾ നടപ്പിലാക്കുന്നതിനുള്ള പദ്ധതികൾ പ്രഖ്യാപിച്ചു. ഇത് "നേർത്ത ക്ലയന്റ്" എന്ന ആശയവുമായി പൊരുത്തപ്പെടുന്നു, ഇതിന്റെ പ്രവർത്തനം ഡാറ്റ പ്രദർശിപ്പിക്കുന്നതിന് മാത്രം ശേഷിക്കുന്നു (വിദൂര ഡാറ്റാ അവതരണ മോഡൽ).

അടുത്തിടെ, വിതരണം ചെയ്ത ആപ്ലിക്കേഷൻ മോഡൽ ഉപയോഗിക്കുന്നതിനുള്ള ഒരു പ്രവണതയും ഉണ്ടായിട്ടുണ്ട്. രണ്ടോ അതിലധികമോ ഭാഗങ്ങളായി ആപ്ലിക്കേഷന്റെ ലോജിക്കൽ ഡിവിഷൻ ആണ് അത്തരം ആപ്ലിക്കേഷനുകളുടെ ഒരു സവിശേഷത, അവ ഓരോന്നും പ്രത്യേക കമ്പ്യൂട്ടറിൽ എക്സിക്യൂട്ട് ചെയ്യാൻ കഴിയും. ആപ്ലിക്കേഷന്റെ സമർപ്പിത ഭാഗങ്ങൾ പരസ്പരം ആശയവിനിമയം നടത്തുന്നു, മുൻകൂട്ടി സമ്മതിച്ച ഫോർമാറ്റിൽ സന്ദേശങ്ങൾ കൈമാറുന്നു. ഈ സാഹചര്യത്തിൽ, രണ്ട്-ടയർ ക്ലയന്റ്-സെർവർ ആർക്കിടെക്ചർ ത്രീ-ടയർ ആയി മാറുന്നു, ചില സന്ദർഭങ്ങളിൽ, അതിൽ കൂടുതൽ ലിങ്കുകൾ ഉൾപ്പെട്ടേക്കാം.

5.1.3. ഇടപാട് മോണിറ്ററുകൾ

ഒരു ഇൻഫർമേഷൻ സിസ്റ്റം ആവശ്യത്തിന് വ്യത്യസ്ത വിവര ഉറവിടങ്ങളും ആപ്ലിക്കേഷൻ സെർവറുകളും സംയോജിപ്പിക്കുമ്പോൾ, അതിന്റെ എല്ലാ ഘടകങ്ങളുടെയും ഒപ്റ്റിമൽ മാനേജ്മെന്റിനെക്കുറിച്ചുള്ള ചോദ്യം ഉയർന്നുവരുന്നു. ഈ സാഹചര്യത്തിൽ, പ്രത്യേക ഉപകരണങ്ങൾ ഉപയോഗിക്കുന്നു - ഇടപാട് പ്രോസസ്സിംഗ് മോണിറ്ററുകൾ (പലപ്പോഴും "ഇടപാട് മോണിറ്ററുകൾ" എന്ന് വിളിക്കുന്നു). അതേസമയം, ഡാറ്റാബേസ് സിദ്ധാന്തത്തിൽ അറിയപ്പെടുന്നതുമായി താരതമ്യപ്പെടുത്തുമ്പോൾ ഒരു ഇടപാട് എന്ന ആശയം വിപുലീകരിക്കപ്പെടുന്നു. ഈ സാഹചര്യത്തിൽ, ഇത് ഡാറ്റാബേസിലെ ഒരു ആറ്റോമിക് പ്രവർത്തനമല്ല, സിസ്റ്റത്തിലെ ഏത് പ്രവർത്തനവും - ഒരു സന്ദേശം നൽകൽ, ഒരു സൂചിക ഫയലിലേക്ക് എഴുതുക, ഒരു റിപ്പോർട്ട് അച്ചടിക്കുക തുടങ്ങിയവ.

ആപ്ലിക്കേഷൻ പ്രോഗ്രാമും ഇടപാട് മോണിറ്ററും തമ്മിൽ ആശയവിനിമയം നടത്താൻ, ഒരു പ്രത്യേക API (അപ്ലിക്കേഷൻ പ്രോഗ്രാം ഇന്റർഫേസ്) ഉപയോഗിക്കുന്നു, ഇത് അടിസ്ഥാന പ്രവർത്തനങ്ങളിലേക്കുള്ള കോളുകൾ അടങ്ങിയ ഒരു ലൈബ്രറിയായി നടപ്പിലാക്കുന്നു (ഒരു കണക്ഷൻ സ്ഥാപിക്കുക, ഒരു നിർദ്ദിഷ്ട സേവനം വിളിക്കുക മുതലായവ). ഈ API ഉപയോഗിച്ചാണ് ആപ്ലിക്കേഷൻ സെർവറുകളും (സേവനങ്ങൾ) സൃഷ്ടിച്ചിരിക്കുന്നത്, ഓരോ സേവനത്തിനും ഒരു തനതായ പേര് നൽകിയിരിക്കുന്നു. ഇടപാട് മോണിറ്റർ, ഒരു ആപ്ലിക്കേഷൻ പ്രോഗ്രാമിൽ നിന്ന് ഒരു അഭ്യർത്ഥന സ്വീകരിച്ച്, ഉചിതമായ സേവനത്തിലേക്ക് അതിന്റെ കോൾ കൈമാറുന്നു (അത് പ്രവർത്തിക്കുന്നില്ലെങ്കിൽ, ആവശ്യമായ പ്രക്രിയ ആരംഭിക്കുന്നു), കൂടാതെ ആപ്ലിക്കേഷൻ സെർവറിന്റെ അഭ്യർത്ഥന പ്രോസസ്സ് ചെയ്ത ശേഷം, അത് ഫലങ്ങൾ ഇനിപ്പറയുന്നതിലേക്ക് തിരികെ നൽകുന്നു കക്ഷി. ഡാറ്റാബേസ് സെർവറുകളുമായുള്ള ഇടപാട് മോണിറ്ററുകളുടെ ഇടപെടലിനായി XA പ്രോട്ടോക്കോൾ വികസിപ്പിച്ചെടുത്തിട്ടുണ്ട്. അത്തരമൊരു ഏകീകൃത ഇന്റർഫേസിന്റെ സാന്നിധ്യം ഒരു ആപ്ലിക്കേഷനിൽ നിരവധി വ്യത്യസ്ത DBMS-കൾ ഉപയോഗിക്കാൻ അനുവദിക്കുന്നു.

വലിയ സിസ്റ്റങ്ങളിൽ ഇടപാട് മോണിറ്ററുകൾ ഉപയോഗിക്കുന്നത് ഇനിപ്പറയുന്ന ആനുകൂല്യങ്ങൾ നൽകുന്നു:

· ആപ്ലിക്കേഷൻ സെർവറിലെ എല്ലാ ആപ്ലിക്കേഷൻ ഫംഗ്‌ഷനുകളുടെയും ഏകാഗ്രത ഉപയോക്തൃ ഇന്റർഫേസ് നടപ്പിലാക്കുന്നതിൽ നിന്നും റിസോഴ്‌സ് മാനേജ്‌മെന്റിന്റെ പ്രത്യേക രീതിയിൽ നിന്നും കാര്യമായ സ്വാതന്ത്ര്യം നൽകുന്നു. ഇത് ആപ്ലിക്കേഷനുകളുടെ കേന്ദ്രീകൃത അഡ്മിനിസ്ട്രേഷൻ ഉറപ്പാക്കുന്നു, കാരണം മുഴുവൻ ആപ്ലിക്കേഷനും ഒരിടത്ത് സ്ഥിതിചെയ്യുന്നു, മാത്രമല്ല ക്ലയന്റ് വർക്ക്സ്റ്റേഷനുകൾക്കിടയിൽ നെറ്റ്‌വർക്കിലുടനീളം വ്യാപിക്കുന്നില്ല.

· ഇടപാട് മോണിറ്ററിന് ആപ്ലിക്കേഷൻ സെർവറുകൾ തന്നെ ആരംഭിക്കാനും നിർത്താനും കഴിയും. നെറ്റ്‌വർക്ക് ലോഡും കമ്പ്യൂട്ടിംഗ് ഉറവിടങ്ങളും അനുസരിച്ച്, ഇതിന് സെർവർ പ്രക്രിയകളുടെ ഒരു ഭാഗം മറ്റ് നോഡുകളിലേക്ക് കൈമാറാനോ പകർത്താനോ കഴിയും. ഇത് ലോഡ് ബാലൻസ് കൈവരിക്കുമെന്ന് ഉറപ്പാക്കുന്നു.

· ഡൈനാമിക് സിസ്റ്റം കോൺഫിഗറേഷൻ നൽകുന്നു, അതായത്. ഒരു പുതിയ റിസോഴ്സ് സെർവർ അല്ലെങ്കിൽ ആപ്ലിക്കേഷൻ സെർവർ നിർത്താതെ തന്നെ ചേർക്കാവുന്നതാണ്.

· സിസ്റ്റത്തിന്റെ വിശ്വാസ്യത വർദ്ധിക്കുന്നു, കാരണം പരാജയങ്ങളുടെ കാര്യത്തിൽ, ആപ്ലിക്കേഷൻ സെർവർ ഒരു ബാക്കപ്പ് കമ്പ്യൂട്ടറിലേക്ക് നീക്കാൻ കഴിയും.

· വിതരണം ചെയ്ത ഡാറ്റാബേസുകൾ കൈകാര്യം ചെയ്യുന്നത് സാധ്യമാകും (കൂടുതൽ വിവരങ്ങൾക്ക്, അടുത്ത ഖണ്ഡിക കാണുക).

5.2 വിതരണം ചെയ്ത ഡാറ്റ പ്രോസസ്സ് ചെയ്യുന്നു

ആധുനിക ബിസിനസ്സിൽ, ഭൂമിശാസ്ത്രപരമായി പരസ്പരം അകലെയുള്ള ഉപയോക്താക്കളുടെ ഗ്രൂപ്പുകൾക്ക് ഒരേ ഡാറ്റയിലേക്ക് ആക്സസ് നൽകേണ്ടത് പലപ്പോഴും ആവശ്യമാണ്. നിരവധി ശാഖകളുള്ള ഒരു ബാങ്ക് ഉദാഹരണം. ഈ ശാഖകൾ വിവിധ നഗരങ്ങളിലോ രാജ്യങ്ങളിലോ വിവിധ ഭൂഖണ്ഡങ്ങളിലോ സ്ഥിതിചെയ്യാം, എന്നിരുന്നാലും, ശാഖകൾക്കിടയിൽ സാമ്പത്തിക ഇടപാടുകൾ (അക്കൗണ്ടുകൾക്കിടയിൽ പണം നീക്കൽ) പ്രോസസ്സിംഗ് സംഘടിപ്പിക്കേണ്ടത് ആവശ്യമാണ്. സാമ്പത്തിക ഇടപാടുകളുടെ ഫലങ്ങൾ എല്ലാ ശാഖകളിലും ഒരേസമയം ദൃശ്യമായിരിക്കണം.

വിതരണം ചെയ്ത ഡാറ്റയുടെ പ്രോസസ്സിംഗ് സംഘടിപ്പിക്കുന്നതിന് രണ്ട് സമീപനങ്ങളുണ്ട്.

1. വിതരണം ചെയ്ത ഡാറ്റാബേസ് സാങ്കേതികവിദ്യ.അത്തരമൊരു ഡാറ്റാബേസിൽ വിവിധ നെറ്റ്‌വർക്ക് നോഡുകളിൽ സ്ഥിതിചെയ്യുന്ന ഡാറ്റയുടെ ശകലങ്ങൾ ഉൾപ്പെടുന്നു. ഉപയോക്താക്കളുടെ കാഴ്ചപ്പാടിൽ, എല്ലാ ഡാറ്റയും ഒരിടത്ത് സംഭരിച്ചിരിക്കുന്നതായി തോന്നുന്നു. സ്വാഭാവികമായും, അത്തരമൊരു പദ്ധതി ആശയവിനിമയ ചാനലുകളുടെ പ്രകടനത്തിലും വിശ്വാസ്യതയിലും കർശനമായ ആവശ്യങ്ങൾ ഉന്നയിക്കുന്നു.

2. അനുകരണ സാങ്കേതികവിദ്യ.ഈ സാഹചര്യത്തിൽ, എല്ലാ കമ്പ്യൂട്ടറുകളുടെയും ഡാറ്റ ഓരോ നെറ്റ്‌വർക്ക് നോഡിലും തനിപ്പകർപ്പാണ്. അതിൽ:

· ഡാറ്റ പരിഷ്‌ക്കരണ പ്രവർത്തനങ്ങൾ മാത്രമേ കൈമാറുന്നുള്ളൂ, ഡാറ്റ തന്നെ അല്ല

· സംപ്രേക്ഷണം അസമന്വിതമാകാം (വ്യത്യസ്ത നോഡുകൾക്ക് ഒരേസമയം അല്ലാത്തത്)

· ഡാറ്റ പ്രോസസ്സ് ചെയ്യുന്നിടത്ത് സ്ഥിതിചെയ്യുന്നു

ആശയവിനിമയ ചാനലുകളുടെ ബാൻഡ്‌വിഡ്‌ത്തിന്റെ ആവശ്യകതകൾ കുറയ്ക്കുന്നത് ഇത് സാധ്യമാക്കുന്നു; കൂടാതെ, ഒരു കമ്പ്യൂട്ടറിന്റെ ആശയവിനിമയ ലൈൻ പരാജയപ്പെടുകയാണെങ്കിൽ, മറ്റ് നോഡുകളുടെ ഉപയോക്താക്കൾക്ക് തുടർന്നും പ്രവർത്തിക്കാനാകും. എന്നിരുന്നാലും, ഒരേ സമയത്ത് വ്യത്യസ്ത ഉപയോക്താക്കൾക്ക് അസമമായ ഡാറ്റാബേസ് അവസ്ഥകൾ ഇത് അനുവദിക്കുന്നു. അതിനാൽ, ഒരേ റെക്കോർഡിന്റെ രണ്ട് പകർപ്പുകൾ തമ്മിലുള്ള വൈരുദ്ധ്യങ്ങൾ ഇല്ലാതാക്കുക അസാധ്യമാണ്.