வலைச் சேவை (web service) என்றால் என்ன?

வலைச் சேவை (web service) என்பது பயன்பாடுகள் நெட்வொர்க் வழியாகத் தரவைப் பரிமாறிக்கொள்ளவோ செயல்பாடுகளை அழைக்கவோ உதவும் இடைமுகம். இணையதளம் முதன்மையாக மனிதர்கள் படிக்கவும் பயன்படுத்தவும் வடிவமைக்கப்படுகிறது; வலைச் சேவையோ மென்பொருள் கிளையன்ட்கள் பின்பற்றுவதற்கான ஒப்பந்தத்தை (contract) வழங்குகிறது. ஒரே தயாரிப்பு இரண்டையும் வழங்கலாம். பல சேவைகள் HTTP-யையும் JSON-ஐயும் பயன்படுத்துகின்றன; ஆனால் இந்தச் சொல் பிற நெறிமுறைகளையும் தரவு வடிவங்களையும் உள்ளடக்கியது.

கோரிக்கையும் பதிலும் எப்படி வேலை செய்கின்றன

கிளையன்ட், வரையறுக்கப்பட்ட endpoint-க்கு ஒரு method, அளவுருக்கள், தேவைப்பட்டால் அங்கீகாரச் சான்றுகள் ஆகியவற்றுடன் கோரிக்கையை அனுப்புகிறது. சேவை கோரிக்கையைச் சரிபார்த்து, தன் செயல்பாட்டைச் செய்து, பதிலைத் திருப்புகிறது. HTTP API-களில் நிலைக் குறியீடுகள் (status codes) பொதுவான விளைவுகளைப் பிரித்துக் காட்டுகின்றன: வெற்றிகரமான பதில், தவறான உள்ளீடு போன்ற கிளையன்ட் பக்கச் சிக்கல், அல்லது சர்வர் பக்கத் தோல்வி. பதிலின் உடல் (body) பொதுவாக ஆவணப்படுத்தப்பட்ட வடிவத்தில் கூடுதல் விவரங்களைத் தருகிறது.

தெளிவான ஒப்பந்தம் பாதைகள், method-கள், புலங்கள், வகைகள், அங்கீகாரம், rate limit-கள், பிழை நிலைகள் ஆகியவற்றை விவரிக்கிறது. இதனால் சேவையைச் சாராமல் கிளையன்ட்களைத் தனியாக உருவாக்க முடிகிறது. பதிப்பு மேலாண்மை (versioning) முக்கியம்: endpoint முகவரி மாறாவிட்டாலும், ஒரு புலத்தையோ அதன் பொருளையோ மாற்றினால் ஏற்கெனவே உள்ள பயன்பாடுகள் உடைந்துவிடலாம். வாக்குறுதி அளித்த இடங்களில் பின்னோக்கு இணக்கத்தைப் (backward compatibility) பேணி, நிறுத்தப்படும் காலங்களை (deprecation periods) முன்கூட்டியே அறிவியுங்கள்.

பொதுவான இடைமுக வகைகள்

REST என்பது ஒரு கட்டமைப்புப் பாணி; ஒற்றைத் தரவுப் பரிமாற்ற வடிவம் அல்ல. RESTful என விவரிக்கப்படும் HTTP API-கள் பொதுவாக வளங்களை URL-களால் குறிக்கின்றன; படிக்க GET, மாற்றங்களுக்கு POST அல்லது PUT போன்ற method-களைப் பயன்படுத்துகின்றன. GET நீடித்த நிலை மாற்றத்தை உருவாக்கக்கூடாது; கிளையன்ட்களும் இடைநிலை அமைப்புகளும் அதை மீண்டும் அனுப்பலாம் அல்லது கேஷ் செய்யலாம். பல நிறுவன அமைப்புகளில் SOAP, கட்டமைக்கப்பட்ட XML செய்திகளையும் முறையான சேவை விவரணைகளையும் பயன்படுத்துகிறது.

GraphQL, ஒரு schema மூலம், பெரும்பாலும் HTTP வழியாக, கிளையன்ட்கள் தேர்ந்தெடுத்த புலங்களை மட்டும் கோர அனுமதிக்கிறது. தேவையற்ற தரவுப் பரிமாற்றத்தை அது குறைக்கலாம்; ஆனால் query செலவு, அனுமதி (authorisation), கேஷ் ஆகியவற்றில் சிக்கலைக் கூட்டுகிறது. Webhook-கள் வழக்கமான polling முறையைத் தலைகீழாக்குகின்றன: ஒரு நிகழ்வு நடக்கும்போது, ஒரு சேவை பதிவுசெய்யப்பட்ட endpoint-ஐ அழைக்கிறது. Webhook-களுக்கு அனுப்புநர் அங்கீகாரம், மறுமுயற்சிக் கையாளுதல், இரட்டை விநியோகத்துக்கு எதிரான பாதுகாப்பு ஆகியவை தேவை. இவற்றில் எதுவுமே எல்லாச் சூழலுக்கும் சிறந்தது என்று சொல்ல முடியாது.

பாதுகாப்பும் தனியுரிமையும்

பயணிக்கும் தரவைப் பாதுகாக்க HTTPS-ஐப் பயன்படுத்தி, சர்வர் சான்றிதழைச் சரிபாருங்கள். பொருத்தமான credential முறையில் அழைப்பவர்களை அங்கீகரித்து, ஒவ்வொரு செயலுக்கும் பொருளுக்கும் தனித்தனியாக அனுமதி வழங்குங்கள். செல்லுபடியான token அதன் scope அனுமதிப்பதை மட்டுமே நிரூபிக்கிறது; தன்னிச்சையான உள்ளீட்டைப் பாதுகாப்பானதாக்குவதில்லை. கோரிக்கையின் அளவையும் வகைகளையும் சரிபாருங்கள், பிழைச் செய்திகளில் தனிப்பட்ட தரவை வெளிப்படுத்தாதீர்கள், தவறான பயன்பாட்டுக்கு எதிராக வரம்புகளை அமையுங்கள்.

ரகசியங்கள் பொது URL-களிலோ கிளையன்ட் பக்க மூலக் குறியீட்டிலோ பதிவுகளிலோ தோன்றக்கூடாது. வெளிப்பட்ட credential-களை மாற்றுங்கள், அவற்றின் scope-ஐக் கட்டுப்படுத்துங்கள், production-க்கும் சோதனைக்கும் தனித்தனி credential-களைப் பயன்படுத்துங்கள். callback URL ஏற்கும் API-களில், உள் நெட்வொர்க்குகளுக்குக் கோரிக்கைகள் செல்வதைத் தடுக்கச் சேருமிடங்களைச் சரிபாருங்கள். எந்தத் தனிப்பட்ட தரவு திருப்பித் தரப்படுகிறது என்பதை ஆவணப்படுத்தி, தேவையானதை மட்டும் வைத்திருங்கள்.

நம்பகத்தன்மையும் செயல்திறனும்

நெட்வொர்க்குகள் தோல்வியடையும்; எனவே கிளையன்ட்களுக்கு timeout-கள், வரம்புக்குட்பட்ட மறுமுயற்சிகள், பகுதித் தோல்விகளைத் தெளிவாகக் கையாளும் முறை ஆகியவை தேவை. பாதுகாப்பாக இருந்தால் படிக்கும் கோரிக்கையை மீண்டும் முயலலாம்; ஆனால் பணம் செலுத்துதல் அல்லது வேறு மாற்றத்தை மீண்டும் முயல, நகல்களைத் தவிர்க்கும் idempotency வடிவமைப்பு தேவை. பெரிய முடிவுகளை pagination பக்கம் பக்கமாகப் பிரித்துத் தருகிறது. நிலையான பொதுத் தரவுக்குக் கேஷ் சுமையைக் குறைக்கலாம்; வேகமாக மாறும் அல்லது தனிப்பட்ட பதில்களுக்குக் கவனமான கேஷ் கொள்கை தேவை.

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

சேவையைத் தேர்வு செய்தல் அல்லது உருவாக்குதல்

பயனர் எதைச் செய்ய வேண்டும், என்ன தரவு பரிமாறப்பட வேண்டும் என்பதிலிருந்து தொடங்குங்கள்; பிறகு கிளையன்ட்கள் செயல்படுத்தக்கூடிய, குழு பராமரிக்கக்கூடிய இடைமுகப் பாணியைத் தேர்ந்தெடுங்கள். வழக்கமான பதில்கள், தவறான வடிவ உள்ளீடு, காலாவதியான credential-கள், அனுமதிகள், pagination, timeout-கள் ஆகியவற்றைச் சோதியுங்கள். எடுத்துக்காட்டுகளைப் புதுப்பித்த நிலையில் வைத்து, உண்மையான பிழைகளைக் காட்டுங்கள். மூன்றாம் தரப்புச் சேவையை ஒருங்கிணைக்கும்போது, அதன் பயன்பாட்டு வரம்புகள், தரவுக் கொள்கை, மாற்ற அறிவிப்புகள் ஆகியவற்றைப் படியுங்கள்; எவ்வளவு வசதியான endpoint ஆனாலும், அதுவும் தோல்வியடையக்கூடிய ஒரு சார்புதான்.