ஒரு API ஆக ஒரு அட்டவணை? மாயைகள் மற்றும் யதார்த்தம்

அறிமுகம்

சேவை தொடர்புகளின் சூழலில் "ஒப்பந்தம்" என்றால் என்ன?

சேவை தொகுதிகள் ஊடாடும் சூழலில், தவிர்க்க முடியாத கேள்வி எழுகிறது: எந்த விதிகளின்படி தொடர்பு நடைபெறுகிறது? ஐடி தயாரிப்புகளில், ஒரு "ஒப்பந்தம்" என்பது அமைப்புகளுக்கு இடையே என்ன தரவு பாய்கிறது மற்றும் அது எவ்வாறு கடத்தப்படுகிறது என்பது பற்றிய முறையான புரிதலைக் குறிக்கிறது. இது தரவு வடிவம் (JSON, Protobuf, முதலியன), கட்டமைப்பு கூறுகள் (புலங்கள், தரவு வகைகள்), தொடர்பு நெறிமுறை (REST, gRPC, செய்தி வரிசைகள்) மற்றும் பிற விவரக்குறிப்புகளை உள்ளடக்கியது.

ஒரு ஒப்பந்தம் வெளிப்படைத்தன்மையை உறுதி செய்கிறது (என்ன பெறப்படுகிறது மற்றும் அனுப்பப்படுகிறது என்பது அனைவருக்கும் தெரியும்), கணிக்கக்கூடிய தன்மை (நாம் ஒப்பந்தத்தைப் புதுப்பித்து பதிப்புகளைப் பராமரிக்க முடியும்), மற்றும் நம்பகத்தன்மை (நாம் நன்கு நிர்வகிக்கப்பட்ட மாற்றங்களைச் செய்தால் நமது அமைப்பு தோல்வியடையாது).

மக்கள் ஏன் தரவுத்தளத்தில் ஒரு அட்டவணையை "ஒப்பந்தமாக" தேர்ந்தெடுக்க முனைகிறார்கள்?

நடைமுறையில், எல்லோரும் மைக்ரோ சர்வீசஸ், "ஒப்பந்தங்கள்" மற்றும் APIகள் பற்றிப் பேசினாலும், மக்கள் பெரும்பாலும் "APIகளை உருவாக்குவதற்குப் பதிலாக தரவுத்தளத்தில் ஒரு பகிரப்பட்ட அட்டவணையை ஏன் உருவாக்கக்கூடாது?" என்ற அணுகுமுறையைப் பின்பற்றுவதைப் பார்க்கிறோம்.

• வரலாற்று அல்லது நிறுவன பழக்கம்: அனைத்தும் எப்போதும் ஒரு நிறுவனத்திற்குள் ஒரு தரவுத்தள அமைப்பில் சேமிக்கப்பட்டிருக்கும் போது, ஏன் சக்கரத்தை மீண்டும் கண்டுபிடிக்க வேண்டும்?

• "விரைவான தீர்வு" மனநிலை: அங்கீகார விதிகளை அமைக்காமலும் API விவரக்குறிப்புகளை வடிவமைக்காமலும் நாங்கள் எழுதுவோம், நீங்கள் படிப்பீர்கள்.

• "பெரிய தரவு" வாதம்: பல்லாயிரக்கணக்கான அல்லது நூற்றுக்கணக்கான ஜிகாபைட் தரவுகளுடன் பணிபுரியும் போது, பகிரப்பட்ட அட்டவணையில் நேரடி பரிமாற்றம் எளிமையானதாகவும், வேகமானதாகவும், மிகவும் சிக்கனமானதாகவும் தோன்றுகிறது, ஆனால் நடைமுறையில், இது அளவிடுதல் மற்றும் செயல்திறன் சிக்கல்களையும் தரவு உரிமை சிக்கல்களையும் உருவாக்குகிறது.

எனவே, தரவு பரிமாற்றத்திற்காக பகிரப்பட்ட அட்டவணையைப் பயன்படுத்துவது திறமையானதாகவும் விரைவான முடிவுகளுக்கு உகந்ததாகவும் தோன்றலாம், ஆனால் அது நீண்ட காலத்திற்கு பல்வேறு தொழில்நுட்ப மற்றும் நிறுவன சவால்களை உருவாக்குகிறது. இருப்பினும், குழுக்கள் தரவு பரிமாற்றத்திற்காக பகிரப்பட்ட அட்டவணைகளைத் தேர்ந்தெடுக்கும்போது, செயல்படுத்தலின் போது அவர்கள் ஏராளமான சிக்கல்களைச் சந்திக்க நேரிடும்.

"தரவுத்தளத்தில் ஒரு அட்டவணை" ஏன் ஒரு ஒப்பந்தம் அல்ல (மற்றும் அது ஏன் ஒரு எதிர்ப்பு வடிவமாகும்).

தெளிவாக வரையறுக்கப்பட்ட இடைமுகம் இல்லாதது

சேவைகள் REST/gRPC/GraphQL வழியாக தொடர்பு கொள்ளும்போது, அவை ஒரு முறையான வரையறையைக் கொண்டுள்ளன: OpenAPI (Swagger), protobuf schemas அல்லது GraphQL schemas. இவை எந்த வளங்கள் (இறுதிப் புள்ளிகள்) கிடைக்கின்றன, எந்த புலங்கள் எதிர்பார்க்கப்படுகின்றன, அவற்றின் வகைகள் மற்றும் கோரிக்கை/பதில் வடிவங்களை விரிவாக வரையறுக்கின்றன. 'ஒரு பகிரப்பட்ட அட்டவணை' ஒரு ஒப்பந்தமாகச் செயல்படும்போது ஒரு முறையான விளக்கம் இல்லை: ஒப்பந்தத்தின் முறையான விளக்கம் இல்லை; அட்டவணைத் திட்டம் (DDL) மட்டுமே கிடைக்கிறது, அதுவும் நன்கு ஆவணப்படுத்தப்படவில்லை. அட்டவணை கட்டமைப்பில் ஏதேனும் சிறிய மாற்றம் (எ.கா., ஒரு நெடுவரிசையைச் சேர்ப்பது அல்லது நீக்குவது, தரவு வகைகளை மாற்றுவது) இந்த அட்டவணையைப் படிக்கும் அல்லது எழுதும் பிற குழுக்களைப் பாதிக்கலாம்.

பதிப்பு மற்றும் பரிணாம சிக்கல்கள்

API பதிப்பு என்பது ஒரு சாதாரண நடைமுறையாகும்: எங்களிடம் v1, v2 மற்றும் பல இருக்கலாம், மேலும் பின்தங்கிய இணக்கத்தன்மையை வைத்திருக்கலாம், பின்னர் படிப்படியாக வாடிக்கையாளர்களை புதிய பதிப்புகளுக்கு நகர்த்தலாம். தரவுத்தள அட்டவணைகளுக்கு, எங்களிடம் DDL செயல்பாடுகள் மட்டுமே உள்ளன (எ.கா., ALTER TABLE ), அவை ஒரு குறிப்பிட்ட DB இயந்திரத்துடன் இறுக்கமாக இணைக்கப்பட்டுள்ளன, மேலும் இடம்பெயர்வுகளை கவனமாக கையாள வேண்டும்.

நுகர்வோர் தங்கள் வினவல்களைப் புதுப்பிக்க வேண்டிய திட்ட மாற்றங்கள் குறித்த விழிப்பூட்டல்களை அனுப்பக்கூடிய மையப்படுத்தப்பட்ட அமைப்பு எதுவும் இல்லை. இதன் விளைவாக, "அண்டர்-தி-டேபிள்" ஒப்பந்தங்கள் ஏற்படக்கூடும்: யாராவது ஒரு அரட்டையில், "நாளை, நாங்கள் நெடுவரிசை X ஐ Y ஆக மாற்றுகிறோம்" என்று இடுகையிடலாம், ஆனால் அனைவரும் சரியான நேரத்தில் தயாராக இருப்பார்கள் என்பதற்கு எந்த உத்தரவாதமும் இல்லை.

தெளிவான உரிமை இல்லை

தெளிவாக வரையறுக்கப்பட்ட API இருக்கும்போது, அது யாருக்குச் சொந்தமானது என்பது தெளிவாகத் தெரியும்: API வெளியீட்டாளராகச் செயல்படும் சேவை. பல குழுக்கள் ஒரே தரவுத்தள அட்டவணையைப் பயன்படுத்தும்போது, கட்டமைப்பை யார் தீர்மானிப்பது, எந்த புலங்களைச் சேமிப்பது, அவற்றை எவ்வாறு விளக்குவது என்பது குறித்து குழப்பம் ஏற்படுகிறது. இதன் விளைவாக, அட்டவணை "யாருடைய சொத்தாக" மாறக்கூடும், மேலும் ஒவ்வொரு மாற்றமும் ஒரு தேடலாக மாறும்: "அவர்கள் பழைய நெடுவரிசையைப் பயன்படுத்துகிறார்களா என்று அந்த மற்ற குழுவுடன் நாங்கள் சரிபார்க்க வேண்டும்!"

பாதுகாப்பு மற்றும் அணுகல் கட்டுப்பாட்டு சிக்கல்கள்

பல குழுக்களுக்கு DB அணுகல் இருந்தால், ஒரு அட்டவணையை யார் படிக்கவும் எழுதவும் முடியும் என்பதைக் கண்காணிப்பது கடினம். அங்கீகரிக்கப்படாத சேவைகள் தரவை அணுக விரும்பாவிட்டாலும், அவற்றை அணுகும் வாய்ப்பு உள்ளது. API மூலம் இதுபோன்ற சிக்கல்களை நிர்வகிப்பது எளிது: அணுகல் உரிமைகளை நீங்கள் கட்டுப்படுத்தலாம் (யார் எந்த முறைகளை அழைக்கலாம்), அங்கீகாரம் மற்றும் அங்கீகாரத்தைப் பயன்படுத்தலாம் மற்றும் யார் என்ன அழைத்தார்கள் என்பதைக் கண்காணிக்கலாம். ஒரு அட்டவணையுடன், இது மிகவும் சிக்கலானது.

உள் கட்டமைப்பைச் சார்ந்திருத்தல்

தரவுகளில் ஏற்படும் எந்தவொரு உள் மாற்றங்களும் (குறியீடுகளை மறுசீரமைத்தல், அட்டவணையைப் பிரித்தல், தரவுத்தளத்தை மாற்றுதல்) உலகளாவிய பிரச்சனையாக மாறும். அட்டவணை ஒரு பொது இடைமுகமாக செயல்பட்டால், அனைத்து வெளிப்புற வாசகர்கள் மற்றும் எழுத்தாளர்களுக்கும் ஆபத்து ஏற்படாமல் உரிமையாளர் உள் மாற்றங்களைச் செய்ய முடியாது.

வலி புள்ளிகள் மற்றும் நடைமுறையில் உள்ள பொதுவான சிக்கல்கள்

மாற்றங்களை ஒருங்கிணைத்தல்

இதுதான் மிகவும் வேதனையான அம்சம்: அடுத்த நாள் திட்டம் மாறும் என்பதை ஒருவர் மற்றொரு குழுவிடம் எவ்வாறு தெரிவிப்பது?

• அட்டவணைப் பதிப்பைப் புதுப்பிப்பதற்கான ஒரு வெற்றிகரமான சூழ்நிலை: உரிமையாளர் பழையதற்கு இணையாக புதுப்பிக்கப்பட்ட திட்டத்துடன் ஒரு புதிய அட்டவணையை உருவாக்குகிறார். பழைய பதிப்பு தற்போதைய நுகர்வோருக்கு அணுகக்கூடியதாக இருக்கும், மேலும் உரிமையாளர் அவர்களுக்கு ஒரு செய்தியை அனுப்புகிறார், "புதிய கட்டமைப்பு கிடைக்கிறது; ஆவணங்கள் மற்றும் காலக்கெடுவைப் பாருங்கள். இரண்டு பதிப்புகளும் இருக்கும்போதே நகர்த்தவும்."

• இருப்பினும், ஒரு OLAP சூழ்நிலையில் அல்லது பெரிய அளவிலான தரவுகளுடன், இரண்டு இணையான அட்டவணைகளைப் பராமரிப்பது ஒரு சாதாரணமான பணி அல்ல. பழைய திட்டத்திலிருந்து புதிய திட்டத்திற்கு தரவை எவ்வாறு நகர்த்துவது என்பதையும் நீங்கள் தீர்மானிக்க வேண்டும். இதற்கு சில நேரங்களில் திட்டமிடப்பட்ட செயலற்ற நேரம் அல்லது மிகவும் அதிநவீன உள்கட்டமைப்பு தேவைப்படலாம். இந்த செயல்முறை அவசியம் ஆபத்து மற்றும் கூடுதல் வேலை இரண்டையும் அறிமுகப்படுத்துகிறது.

தரவு ஒருமைப்பாடு சிக்கல்கள்

பல குழுக்கள் முக்கியமான தரவைத் தேர்ந்தெடுத்து புதுப்பிக்க பகிரப்பட்ட அட்டவணையைப் பயன்படுத்தும்போது, அது எளிதில் ஒரு "போர்க்களமாக" மாறும். இதன் விளைவாக, வணிக தர்க்கம் பல்வேறு சேவைகளில் சிதறடிக்கப்படுகிறது, மேலும் தரவு ஒருமைப்பாட்டின் மையப்படுத்தப்பட்ட கட்டுப்பாடு இல்லை. ஒரு குறிப்பிட்ட புலம் ஏன் ஒரு குறிப்பிட்ட வழியில் சேமிக்கப்படுகிறது, யார் அதைப் புதுப்பிக்க முடியும், அது காலியாக விடப்பட்டால் என்ன நடக்கும் என்பதை அறிவது மிகவும் கடினமாகிறது.

பிழைத்திருத்தம் மற்றும் கண்காணிப்பு சவால்கள்

உதாரணமாக, அட்டவணை உடைந்து விட்டதாக வைத்துக்கொள்வோம்: தவறான தரவு உள்ளது அல்லது யாரோ ஒருவர் சில முக்கியமான வரிசைகளில் பூட்டை எடுத்துள்ளார் என்று வைத்துக்கொள்வோம். சிக்கலின் மூலத்தை அடையாளம் காண, DB அணுகல் உள்ள ஒவ்வொரு குழுவையும் எந்த வினவல் சிக்கலை ஏற்படுத்தியது என்பதைத் தீர்மானிக்கக் கேட்க வேண்டியிருக்கும். இது பெரும்பாலும் வெளிப்படையாக இருக்காது: இதன் பொருள் ஒரு குழுவின் வினவல் தரவுத்தளத்தைப் பூட்டியிருக்கலாம், அதே நேரத்தில் மற்றொரு குழுவின் வினவல் கவனிக்கத்தக்க பிழையை உருவாக்குகிறது.

ஒற்றை-முனை செயலிழப்பு அனைவரையும் கீழே இழுக்கிறது.

பகிரப்பட்ட தரவுத்தளம் என்பது தோல்வியின் ஒரு புள்ளியாகும். அது செயலிழந்தால், அதனுடன் பல சேவைகளும் செயலிழந்துவிடும். ஒரு சேவையின் கடுமையான வினவல்கள் காரணமாக தரவுத்தளத்தில் செயல்திறனில் சிக்கல்கள் இருக்கும்போது, அனைத்து சேவைகளும் சிக்கல்களை சந்திக்கின்றன. தெளிவான APIகள் மற்றும் தரவு உரிமையைக் கொண்ட ஒரு மாதிரியில், ஒவ்வொரு குழுவும் தங்கள் சேவையின் கிடைக்கும் தன்மை மற்றும் செயல்திறனில் தேர்ச்சி பெற்றவர்கள், எனவே ஒரு கூறுகளில் ஏற்படும் தோல்வி மற்றவர்களுக்கு பரவாது.

தனி படிக்க மட்டும் பிரதியை வழங்குவது சிக்கலை தீர்க்காது.

ஒரு பொதுவான சமரசம் என்னவென்றால்: "எங்கள் முக்கிய தரவுத்தளத்தை பாதிக்காமல் நீங்கள் வினவக்கூடிய வகையில் படிக்க மட்டும் உள்ள பிரதியை நாங்கள் உங்களுக்கு வழங்குவோம்." முதலில், அது சில சுமை சிக்கல்களை தீர்க்கக்கூடும், ஆனால்:

• பதிப்பு சிக்கல்கள் இன்னும் உள்ளன. முக்கிய பிரச்சனை என்னவென்றால், பிரதான அட்டவணை அமைப்பு மாறும்போது, பிரதியின் அமைப்பும் சிறிது தாமதத்துடன் மாறுகிறது.

• பிரதிபலிப்பு தாமதம் தரவு நிலைகளை கணிக்க முடியாததாக மாற்றும், குறிப்பாக பெரிய தரவுத்தொகுப்புகளுடன்.

• உரிமை இன்னும் தெளிவாகத் தெரியவில்லை: வடிவம், கட்டமைப்பு மற்றும் பயன்பாட்டு விதிகளை யார் வரையறுக்கிறார்கள்? ஒரு பிரதி இன்னும் வேறொருவரின் தரவுத்தளத்தின் "ஒரு பகுதி" தான்.

சேவை தொடர்புகளை எவ்வாறு சரியாக வடிவமைப்பது (ஒப்பந்தம் முதலில்)

ஒப்பந்தத்தின் தெளிவான வரையறை.

நவீன வடிவமைப்பு நடைமுறைகள் (எடுத்துக்காட்டாக, "API First" அல்லது "Contract First") ஒரு முறையான இடைமுக வரையறையுடன் தொடங்குகின்றன. OpenAPI/Swagger, protobuf அல்லது GraphQL திட்டங்கள் பயன்படுத்தப்படுகின்றன. இந்த வழியில், எந்த இறுதிப் புள்ளிகள் கிடைக்கின்றன, எந்த புலங்கள் தேவை, மற்றும் எந்த தரவு வகைகள் பயன்படுத்தப்படுகின்றன என்பதை மக்கள் மற்றும் இயந்திரங்கள் இருவரும் அறிவார்கள்.

தரவு உரிமையாளராக சேவை

ஒரு மைக்ரோ சர்வீசஸ் (அல்லது மட்டு) கட்டமைப்பில், ஒவ்வொரு சேவையும் அதன் தரவை முழுவதுமாக சொந்தமாகக் கொண்டுள்ளது என்பது அனுமானம். இது கட்டமைப்பு, சேமிப்பு மற்றும் வணிக தர்க்கத்தை வரையறுக்கிறது மற்றும் அந்த APIக்கான அனைத்து வெளிப்புற அணுகலுக்கும் ஒரு API ஐ வழங்குகிறது. 'வேறொருவரின்' தரவுத்தளத்தை யாரும் தொட முடியாது: அதிகாரப்பூர்வ இறுதிப் புள்ளிகள் அல்லது நிகழ்வுகள் மட்டுமே. மாற்றங்கள் கேள்விக்குறியாக இருக்கும் போதெல்லாம் இது வாழ்க்கையை எளிதாக்குகிறது, மேலும் யாரைக் குறை கூறுவது என்பது எப்போதும் தெளிவாகிறது.

செயல்படுத்தல் எடுத்துக்காட்டுகள்

• REST/HTTP: ஒரு சேவை GET /items , POST /items போன்ற இறுதிப் புள்ளிகளை வெளியிடுகிறது, மேலும் வாடிக்கையாளர்கள் நன்கு வரையறுக்கப்பட்ட தரவுத் திட்டம் (DTO) மூலம் கோரிக்கைகளைச் செய்கிறார்கள்.

• gRPC / பைனரி நெறிமுறைகள்: gRPC/protobuf இல், சேவை மற்றும் செய்திகள் முறையாக .proto கோப்புகளில் வரையறுக்கப்படுகின்றன, மேலும் .proto கோப்புகளில் மாற்றங்கள் செய்யப்படுகின்றன, அங்கு முறை, கோரிக்கை மற்றும் பதில் வரையறுக்கப்படுகின்றன.

• நிகழ்வு சார்ந்தது: தரவுகளை வைத்திருக்கும் சேவை, காஃப்கா அல்லது ராபிட்எம்க்யூ போன்ற தரகருக்கு நிகழ்வுகளை வெளியிடுகிறது, மேலும் சந்தாதாரர்கள் அவற்றைப் பயன்படுத்துகிறார்கள். இங்குள்ள ஒப்பந்தம் நிகழ்வு வடிவமாகும். பதிப்பு செய்யப்பட்ட தலைப்புகள் அல்லது செய்திகள் மூலம் கட்டமைப்பு மாற்றங்கள் செய்யப்படுகின்றன.

பதிப்பு கட்டுப்பாடு

எந்த மாதிரியாக இருந்தாலும், இடைமுகத்தில் பதிப்பு கட்டுப்பாட்டை செயல்படுத்துவது சாத்தியம் மற்றும் அவசியம். எடுத்துக்காட்டாக:

• REST-ல், /api/v1/… மற்றும் /api/v2/ உள்ளன.

• gRPC/protobuf உடன், பின்னோக்கிய/முன்னோக்கிய இணக்கத்தன்மைக்கு சக்திவாய்ந்த வழிமுறைகள் உள்ளன - புதிய புலங்கள், செய்திகள் மற்றும் முறைகள் பழைய கிளையண்டுகளை உடைக்காமல் சேர்க்கப்படலாம், மற்றவை காலாவதியானதாகக் குறிக்கப்படுகின்றன.

• நிகழ்வு சார்ந்த கட்டமைப்புகளில், அனைத்து நுகர்வோரும் இடம்பெயரும் வரை பழைய மற்றும் புதிய நிகழ்வு வடிவங்களை இணையாக வெளியிடலாம்.

பகிர்ந்தளிக்கப்பட்ட பொறுப்பு

ஒரு அடிப்படைக் கொள்கை என்னவென்றால், தரவை வைத்திருக்கும் குழு அதை எவ்வாறு சேமித்து நிர்வகிப்பது என்பதை முடிவு செய்ய வேண்டும், ஆனால் அவர்கள் மற்ற சேவைகளுக்கு நேரடி எழுத்து அணுகலை வழங்கக்கூடாது. மற்றவர்கள் வெளிநாட்டுத் தரவைத் திருத்துவதற்கு மாறாக API வழியாகச் செல்ல வேண்டும். இது தெளிவான பொறுப்பு விநியோகத்தை அளிக்கிறது: சேவை A உடைந்தால், அதைச் சரிசெய்வது சேவை A இன் பொறுப்பாகும், அதன் அண்டை நாடுகளுக்கு அல்ல.

சேவை தொடர்புக்கான எடுத்துக்காட்டுகள்

ஒற்றை அணிக்குள்

முதல் பார்வையில், எல்லாம் ஒரே குழுவில் இருந்தால், ஏன் ஒரு API மூலம் விஷயங்களை சிக்கலாக்க வேண்டும்? உண்மையில், உங்களிடம் ஒரு தயாரிப்பு தொகுதிகளாகப் பிரிக்கப்பட்டிருந்தாலும், பகிரப்பட்ட அட்டவணை அதே சிக்கல்களுக்கு வழிவகுக்கும்.

• உதாரணமாக, `ஆர்டர்கள்` அட்டவணையை சொந்தமாகக் கொண்ட ஒரு “முகப்பு” அல்லது “மைக்ரோ சர்வீஸ்” ஐ உருவாக்குவது நல்லது, பின்னர் பிற தொகுதிகள் (பகுப்பாய்வு போன்றவை) இந்த முகப்பு/சேவையை அழைக்கின்றன.

• இது ஒப்பந்தக் கொள்கையை வெளிப்படையாக வைத்திருக்கிறது மற்றும் பிழைத்திருத்தத்தை எளிதாக்குகிறது.

எடுத்துக்காட்டாக, ஆர்டர்கள் சேவை ஆர்டர்கள் அட்டவணையின் உரிமையாளராக உள்ளது, மேலும் பில்லிங் சேவை அந்த அட்டவணையை நேரடியாக அணுகாது - ஆர்டர் விவரங்களைப் பெற அல்லது ஒரு ஆர்டரை பணம் செலுத்தியதாகக் குறிக்க ஆர்டர்கள் சேவையின் இறுதிப் புள்ளிகளுக்கு அழைப்புகளைச் செய்கிறது.

இரண்டு அணிகளுக்கு இடையில்

உயர் மட்டத்தில், இரண்டு அல்லது அதற்கு மேற்பட்ட அணிகள் வெவ்வேறு பகுதிகளுக்குப் பொறுப்பேற்றால், கொள்கைகள் அப்படியே இருக்கும். உதாரணமாக:

• ஒவ்வொரு பொருளைப் பற்றிய தகவல்களையும் (விலை, கிடைக்கும் தன்மை, பண்புக்கூறுகள்) கொண்ட தயாரிப்பு பட்டியல் சேவைக்கு குழு A பொறுப்பாகும்.

• ஷாப்பிங் கூடை சேவையை குழு B கவனித்துக்கொள்கிறது.

குழு B நேரடியாக குழு A க்கு சொந்தமான "பட்டியல்" அட்டவணையை வினவினால், A இல் ஏதேனும் உள் திட்ட மாற்றங்கள் (எ.கா. புலங்களைச் சேர்ப்பது, கட்டமைப்பை மாற்றுவது) குழு B ஐப் பாதிக்கலாம்.

சரியான அணுகுமுறை API ஐப் பயன்படுத்துவதாகும்: குழு A GET /catalog/items , GET /catalog/items/{id} போன்ற இறுதிப் புள்ளிகளை வழங்குகிறது, மேலும் குழு B அந்த முறைகளைப் பயன்படுத்துகிறது. A பழைய மற்றும் புதிய பதிப்புகளை ஆதரிக்க முடிந்தால், அவர்கள் /v2 ஐ வெளியிடலாம், இது B க்கு இடம்பெயர நேரம் அளிக்கிறது.

நிறுவன அம்சங்கள் மற்றும் நன்மைகள்

வெளிப்படையான தொடர்பு

ஒரு முறையான ஒப்பந்தத்தில், அனைத்து மாற்றங்களும் தெரியும்: Swagger/OpenAPI, .proto கோப்புகள் அல்லது நிகழ்வு ஆவணங்களில். எந்தவொரு புதுப்பிப்பையும் முன்கூட்டியே விவாதிக்கலாம், முறையாக சோதிக்கலாம் மற்றும் தேவைக்கேற்ப பின்னோக்கிய இணக்கத்தன்மை உத்திகளுடன் திட்டமிடலாம்.

வேகமான வளர்ச்சி

ஒரு சேவையில் ஏற்படும் மாற்றங்கள் மற்றவற்றில் குறைவான தாக்கத்தையே ஏற்படுத்தும். புதிய மற்றும் பழைய புலங்கள் அல்லது இறுதிப் புள்ளிகளை முறையாக நிர்வகித்து, சீரான மாற்றத்தை உறுதி செய்தால், குழு வேறொருவரை "உடைப்பது" பற்றி கவலைப்பட வேண்டியதில்லை.

அணுகல் மற்றும் பாதுகாப்பு மேலாண்மை

API நுழைவாயில்கள், அங்கீகாரம் மற்றும் அங்கீகாரம் (JWT, OAuth) ஆகியவை சேவைகளுக்கு நிலையானவை, ஆனால் பகிரப்பட்ட அட்டவணையுடன் கிட்டத்தட்ட சாத்தியமற்றது. அணுகலை (யார் எந்த முறைகளை அழைக்கலாம்) நன்றாகச் சரிசெய்வது, பதிவுகளை வைத்திருப்பது, பயன்பாட்டு புள்ளிவிவரங்களைக் கண்காணிப்பது மற்றும் ஒதுக்கீடுகளை விதிப்பது எளிது. இது அமைப்பைப் பாதுகாப்பானதாகவும் மேலும் கணிக்கக்கூடியதாகவும் ஆக்குகிறது.

முடிவுரை

தரவுத்தளத்தில் பகிரப்பட்ட அட்டவணை என்பது சேவைகளுக்கு இடையிலான ஒப்பந்தத்தை விட செயல்படுத்தல் விவரமாகும், எனவே இது ஒரு ஒப்பந்தமாகக் கருதப்படுவதில்லை. பல சிக்கல்கள் (சிக்கலான பதிப்பு, குழப்பமான மாற்றங்கள், தெளிவற்ற உரிமை, பாதுகாப்பு மற்றும் செயல்திறன் அபாயங்கள்) இந்த அணுகுமுறையை நீண்ட காலத்திற்கு ஏற்றுக்கொள்ள முடியாததாக ஆக்குகின்றன.

சரியான அணுகுமுறை ஒப்பந்தம் முதலில் , அதாவது முறையான வடிவமைப்பு மூலம் தொடர்புகளை வரையறுத்து, ஒவ்வொரு சேவையும் அதன் தரவின் உரிமையாளராகவே இருக்கும் என்ற கொள்கையைப் பின்பற்றுவதாகும். இது தொழில்நுட்பக் கடனைக் குறைக்க உதவுவது மட்டுமல்லாமல், வெளிப்படைத்தன்மையை அதிகரிக்கிறது, தயாரிப்பு மேம்பாட்டை துரிதப்படுத்துகிறது மற்றும் தரவுத்தளத் திட்டங்களில் தீயணைப்பு நடவடிக்கைகளில் ஈடுபடாமல் பாதுகாப்பான மாற்றங்களைச் செயல்படுத்துகிறது.

இது ஒரு தொழில்நுட்பப் பிரச்சினை (வடிவமைப்பது மற்றும் ஒருங்கிணைப்பது எப்படி) மற்றும் ஒரு நிறுவனப் பிரச்சினை (குழுக்கள் மாற்றங்களை எவ்வாறு தொடர்பு கொள்வது மற்றும் நிர்வகிப்பது) இரண்டும் ஆகும். தரவுத்தளத் திட்டங்கள் தொடர்பான முடிவற்ற அவசரநிலைகளைச் சமாளிக்காமல் உங்கள் தயாரிப்பு வளர விரும்பினால், நேரடி தரவுத்தள அணுகலை விட ஒப்பந்தங்களின் அடிப்படையில் சிந்திக்கத் தொடங்க வேண்டும்.