பொருளடக்கம்:
- உன் வீட்டுப்பாடத்தை செய்
- சீரான இருக்க
- OAuth ஐப் பயன்படுத்துக
- ஆரம்பத்தில் தொடங்குங்கள்
- நல்ல ஆவணங்களை எழுதுங்கள்
- ஏபிஐ மேம்பாடு: இதை எளிமையாக வைத்திருங்கள்
இது மென்பொருள் உருவாக்கத்தின் இயல்பு. டெவலப்பர்கள் இறுதி பயனரை மனதில் கொண்டு மென்பொருளை உருவாக்குகிறார்கள். இது மிகவும் எளிமையானதாகத் தெரிகிறது, ஆனால் சில நேரங்களில் அந்த பயனர்களும் சக டெவலப்பர்கள். அவர்களுக்காக உடைக்கப்பட்ட விஷயங்கள் அவர்களுக்கு தேவையில்லை. அவர்களுக்கு எளிமை கூட தேவையில்லை. அவர்கள் விரும்புவது அணுகல் மட்டுமே - உங்கள் மென்பொருளை அவர்களுடன் ஒருங்கிணைக்க ஒரு வழி. இங்குதான் ஒரு ஏபிஐ (பயன்பாட்டு நிரலாக்க இடைமுகம்) வருகிறது. வெற்றிகரமான ஏபிஐ உருவாக்க நீங்கள் எடுக்கக்கூடிய ஐந்து படிகளை முன்னிலைப்படுத்த நம்புகிறேன்.
உன் வீட்டுப்பாடத்தை செய்
மென்பொருள் மேம்பாட்டுக்கு வரும்போது, நம்மில் யாரும் சக்கரத்தை மீண்டும் உருவாக்க விரும்பவில்லை. இந்த கட்டத்தில், கிட்டத்தட்ட அனைத்து பெரிய வலை நிறுவனங்களும் தங்கள் மென்பொருள் தயாரிப்புகளுக்கான API களைக் கொண்டுள்ளன. இந்த API களைப் படித்து, அவற்றை உருவாக்கும் வெவ்வேறு வடிவமைப்பு முடிவுகளை எடுக்க முயற்சிக்கவும்.
அங்கு பலவிதமான தொழில்நுட்பங்கள் உள்ளன, ஆனால் நீங்கள் பார்க்கும் பெரும்பாலான API கள் ஒரு RESTful இடைமுகம் அல்லது SOAP ஐப் பயன்படுத்தப் போகின்றன. நீங்கள் எந்த API இடைமுகத்தைப் பயன்படுத்தப் போகிறீர்கள் என்று வேலியில் இருந்தால், HTTP நெறிமுறையைப் பயன்படுத்தி RESTful அணுகுமுறையுடன் செல்ல பரிந்துரைக்கிறேன். இது SOAP ஐ விட எளிமையானது, இது தற்போது மிகவும் பிரபலமானது, மேலும் இணைய அடிப்படையிலான மென்பொருள் தயாரிப்பைப் பயன்படுத்தும் போது தொடங்குவது எளிதாக இருக்கும்.
சீரான இருக்க
டெவலப்பர்கள் மிகவும் பாராட்டும் விஷயங்களில் ஒன்று நிலைத்தன்மை. இது மற்றவற்றுடன், முகவரி, உள்ளீட்டு வாதங்கள், வெளியீட்டு வடிவங்கள் மற்றும் பிழை கையாளுதல் ஆகியவை அடங்கும்.
RESTful அணுகுமுறையைப் பயன்படுத்தும் போது, பல்வேறு URI பெயரிடும் திட்டங்கள் உள்ளன. ஒவ்வொருவருக்கும் அதன் ஆதரவாளர்கள் உள்ளனர், எனவே ஒன்றைத் தேர்ந்தெடுத்து அதனுடன் ஒட்டிக்கொள்க. உள்ளீடு மற்றும் வெளியீட்டு கட்டமைப்போடு இது செல்கிறது. பெரும்பாலான API கள் உள்ளீடு மற்றும் வெளியீட்டு வடிவங்களாக XML மற்றும் JSON ஐப் பயன்படுத்துவதை ஆதரிக்கின்றன. இரண்டையும் ஆதரிக்க நான் பரிந்துரைக்கிறேன், ஆனால் இயல்புநிலை வடிவமைப்பைத் தேர்வுசெய்க.
உள்ளீட்டைப் பொறுத்தவரை, உங்கள் உள்ளீட்டுத் தேவைகள் தொடர்ந்து பெயரிடப்பட வேண்டும், மேலும் நீங்கள் செய்யும் API அழைப்பின் சூழலில் அர்த்தமுள்ளதாக இருக்க வேண்டும். வெளியீட்டிற்கு, நீங்கள் பொதுவான தரவு கட்டமைப்பு தளவமைப்புகளைப் பயன்படுத்துகிறீர்கள் என்பதை உறுதிப்படுத்திக் கொள்ளுங்கள். ஒரு API அழைப்பின் வெளியீட்டை நீங்கள் மடிக்கிறீர்கள் என்றால் a
நீங்கள் வாடிக்கையாளருக்கு திருப்பி அனுப்பும் வெளியீட்டு தரவில் ஒருவித நிலைக் கொடியைச் சேர்ப்பது பொதுவான நடைமுறையாகும். RESTful API அணுகுமுறையைப் பயன்படுத்தும் போது, இது HTTP நிலைக் குறியீடுகளைப் பயன்படுத்தி செய்யப்பட வேண்டும். உதாரணமாக, நீங்கள் ஏற்கனவே இருக்கும் தரவு பொருளில் ஒரு PUT கோரிக்கையை செயலாக்கினால், உங்கள் பதிலில் நீங்கள் சேர்க்கும் HTTP நிலைக் குறியீடு கோரிக்கையின் முடிவைப் பொறுத்து மாறுபடும்.
அழைப்பின் நிலையைக் குறிக்கும் தன்னிச்சையான கொடிக்கு பதிலாக, கோரிக்கை வெற்றிகரமாக இருப்பதைக் குறிக்க ஒரு நிலையான "200 சரி" நிலைக் குறியீட்டைப் பயன்படுத்தலாம், அதே நேரத்தில் கோரிக்கை என்பதைக் குறிக்க "400 மோசமான கோரிக்கை" நிலைக் குறியீட்டைப் பயன்படுத்தலாம். தவறான வடிவமைப்பில். வெவ்வேறு சூழ்நிலைகளில் பயன்படுத்தக்கூடிய சில HTTP நிலைக் குறியீடுகள் உள்ளன.
OAuth ஐப் பயன்படுத்துக
பெரும்பாலான மென்பொருள் தயாரிப்புகள் அந்த பயனருக்கான பாதுகாக்கப்பட்ட வளங்களை அணுக ஒருவித பயனர் அங்கீகாரத்தை உள்ளடக்கும். ஏபிஐகளுக்கு வரும்போது, உங்கள் சேவையகத்திற்கு அனுப்ப பயனர் நற்சான்றிதழ்களை வாடிக்கையாளர் சேகரிப்பது மோசமான நடைமுறையாகும். இங்குதான் OAuth வருகிறது.
மூன்றாம் தரப்பு பயனர்பெயர் / கடவுச்சொல் அங்கீகாரத்தை விட OAuth பல நன்மைகளை வழங்குகிறது. எல்லாவற்றிற்கும் மேலாக, வாடிக்கையாளருக்கு ஒருபோதும் பயனரின் நற்சான்றிதழ்களை அணுக முடியாது. அவர் அல்லது அவள் உள்நுழையும்போது பயனர் உங்கள் சேவையகத்திற்கு திருப்பி விடப்படுவார். பயனர் உங்கள் தளத்திற்கு உள்நுழைந்த பிறகு, அவர் அல்லது அவள் மீண்டும் வாடிக்கையாளருக்கு திருப்பி விடப்படுவார்கள், அங்கு பாதுகாக்கப்பட்ட ஆதாரங்களுக்கான எதிர்கால கோரிக்கைகளில் பயன்படுத்த வாடிக்கையாளர் அணுகல் டோக்கனைப் பெறுவார்.
OAuth ஐப் பயன்படுத்துவதன் மற்றொரு முக்கியமான நன்மை, எந்த நேரத்திலும் கிளையன்ட் அணுகலை ரத்து செய்வதற்கான பயனரின் திறன். எந்தவொரு காரணத்திற்காகவும், வாடிக்கையாளர் தங்கள் சார்பாக பாதுகாக்கப்பட்ட வளங்களை அணுகுவதை அவர்கள் இனி விரும்பவில்லை எனில், அவர்கள் உருவாக்கிய இடைமுகத்திற்குச் சென்று வாடிக்கையாளரின் அணுகலை ரத்து செய்வார்கள்.
ஆரம்பத்தில் தொடங்குங்கள்
உங்கள் API ஐ வெற்றிகரமாக மாற்ற நீங்கள் செய்யக்கூடிய மிக முக்கியமான விஷயங்களில் ஒன்று ஆரம்பத்தில் தொடங்குவதாகும். உங்கள் தரவுத்தளத்தில் சில உள்ளீட்டை உருவாக்க அந்த செயல்பாட்டை நீங்கள் எழுதும்போது, மேலே சென்று கூடுதல் நேரம் எடுத்து அதற்காக ஒரு API இடைமுகத்தை எழுதவும்.நல்ல ஆவணங்களை எழுதுங்கள்
நல்ல ஆவணங்கள் இல்லாததை விட வேகமாக எதுவும் API ஐக் கொல்லாது. சில டெவலப்பர்கள் மோசமாக ஆவணப்படுத்தப்பட்ட ஏபிஐ எடுத்து, அது எவ்வாறு செயல்பட வேண்டும் என்பதைக் கண்டுபிடிக்க முடியும் என்றாலும், பெரும்பாலானவர்கள் அதை விரும்ப மாட்டார்கள்.
உங்களிடம் உள்ள ஒவ்வொரு ஏபிஐ அழைப்பையும் ஆவணப்படுத்த வேண்டும் மற்றும் உங்கள் ஏபிஐ அழைப்புகளை அவை செயல்படும் தரவு வகைகளால் வகைப்படுத்த வேண்டும். ஏபிஐ அழைப்பிற்கான இறுதி புள்ளிகளை ஆவணப்படுத்துவதோடு, தேவையான மற்றும் விருப்ப உள்ளீட்டு வாதங்களையும் வெளியீட்டு தரவு கட்டமைப்புகளையும் நீங்கள் முறையாக வரையறுக்க வேண்டும். உள்ளீட்டு வாதங்கள் ஒன்று இருந்தால் இயல்புநிலை மதிப்பை பட்டியலிட வேண்டும், மேலும் எண் அல்லது சரம் போன்ற எதிர்பார்க்கப்படும் தரவு வடிவமைப்பையும் குறிக்க வேண்டும். கடைசியாக, ஒவ்வொரு API அழைப்பிலும் பிழை நிலைமைகள் மற்றும் நிலைக் குறியீடுகளின் பட்டியல் இருக்க வேண்டும்.
உங்கள் ஆவணமாக்கலைச் சுற்றிலும், ஒவ்வொரு ஏபிஐ அழைப்பிற்கும் பொதுவான உள்ளீடு மற்றும் வெளியீட்டு காட்சிகளுக்கு ஒன்று அல்லது இரண்டு எடுத்துக்காட்டுகளைச் சேர்க்க மறக்காதீர்கள்.
ஏபிஐ மேம்பாடு: இதை எளிமையாக வைத்திருங்கள்
ஒரு API ஐ உருவாக்குவது ஒரு சிக்கலான முயற்சி என்று தோன்றலாம் என்றாலும், ஒரு API இன் யோசனை ஒரு புதிய கருத்து அல்ல, மேலும் நாம் இங்கு தொட்ட ஒவ்வொரு தலைப்பிலும் ஏராளமான ஆவணங்கள் உள்ளன. நீங்கள் அவற்றைக் கண்டுபிடிக்கக்கூடிய நல்ல நடைமுறைகளைப் பயன்படுத்துவதை உறுதிப்படுத்திக் கொள்ளுங்கள், மேலும் நிலையான, நன்கு ஆவணப்படுத்தப்பட்ட இடைமுகத்தை வழங்கவும்.
