CodeGym /Java Course /தொகுதி 3 /HttpClient உடன் கோரிக்கை வைத்தல்

HttpClient உடன் கோரிக்கை வைத்தல்

தொகுதி 3
நிலை 10 , பாடம் 3
கிடைக்கப்பெறுகிறது

4.1 அனுப்பு() முறை, BodyHandlers

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


HttpRequest request = HttpRequest.newBuilder(new URI("https://codegym.cc")).build();
 
   HttpClient client = HttpClient.newBuilder()
        .version(Version.HTTP_1_1)
        .build();
 
   HttpResponse<String> response = client.send(request, BodyHandlers.ofString());
   System.out.println(response.statusCode() );
   System.out.println(response.body() ); 

மேலும் இவை என்ன BodyHandlers? நீங்கள் என்ன நினைக்கறீர்கள்? நீங்கள் ஒரு கோரிக்கையை அனுப்பியுள்ளீர்கள், அதாவது நீங்கள் ஒரு பதிலைப் பெற வேண்டும் - http response. இந்த பதிலில் இருக்க முடியும் response body: ஒரு சரம், ஒரு கோப்பு, பைட்டுகளின் வரிசை, ஒரு உள்ளீடு ஸ்ட்ரீம்.

ஆம், ஆம், அது சரிதான். கோரிக்கையை உருவாக்கும் போது, response body​​பதில் வகையை நீங்கள் குறிப்பிட வேண்டும். மொத்தம் 8 துண்டுகள் இருக்கலாம்:

  • BodyHandlers.ofByteArray
  • BodyHandlers.ofString
  • BodyHandlers.ofFile
  • BodyHandlers.discarding
  • BodyHandlers.replacing
  • BodyHandlers.ofLines
  • BodyHandlers.fromLineSubscriber

BodyHandlersநீங்கள் எந்த வகை முறையைப் பெற்றீர்கள் என்பதைப் பொறுத்து send(), அது அத்தகைய முடிவு வகையை வழங்கும். உதாரணமாக:

// response body is ignored
HttpResponse<Void> response = client.send(request, BodyHandlers.discarding());
// response body is a string
 HttpResponse<String>response = client.send(request, BodyHandlers.ofString());
// response body is a file
HttpResponse<Path> response = client.send(request, BodyHandlers.ofFile(Paths.get("readme.txt")));
// response body is an InputStream
HttpResponse<InputStream> response = client.send(request, BodyHandlers.ofInputStream());

ஒரு கோப்பு உங்களுக்கு மறுமொழியாக அனுப்பப்பட்டால், BodyHandlers.ofFile()நீங்கள் உள்ளூர் கோப்பின் பெயரை முறைக்கு அனுப்ப வேண்டும், அங்கு அது HttpClient பொருளால் சேமிக்கப்படும்.

4.2 followRedirects() முறை

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

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

HttpResponse response = HttpClient.newBuilder()
  .followRedirects( HttpClient.Redirect.ALWAYS )
  .build()
  .send(request, BodyHandlers.ofString());

திசைதிருப்பலுக்கு 3 விருப்பங்கள் மட்டுமே உள்ளன:

  • எப்போதும் - எப்போதும்;
  • ஒருபோதும் - ஒருபோதும்;
  • இயல்பானது - எப்போதும், HTTPS -> HTTP தவிர.

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

4.4 ப்ராக்ஸி() முறை

இன்னும் சில பயனுள்ள, ஆனால் அடிக்கடி பயன்படுத்தப்படாத விருப்பங்கள் உள்ளன. உங்களுக்குத் தேவைப்படும் வரை அவை உங்களுக்குத் தேவையில்லை :)

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

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

ப்ராக்ஸியை அமைப்பது மிகவும் எளிது - ஒரு எடுத்துக்காட்டு:

HttpResponse<String> response = HttpClient.newBuilder()
  .proxy( ProxySelector.getDefault())
  .build()
  .send(request, BodyHandlers.ofString());

இயல்புநிலை ப்ராக்ஸி இங்கே தேர்ந்தெடுக்கப்பட்டது, ஆனால் நீங்கள் சொந்தமாக அமைக்க விரும்பலாம்:

HttpResponse response = HttpClient.newBuilder()
  .proxy(ProxySelector.of(new InetSocketAddress("proxy.microsoft.com", 80)))
  .build()
  .send(request, BodyHandlers.ofString());

ப்ராக்ஸியுடன் எவ்வாறு சரியாக வேலை செய்வது என்பதை நாங்கள் கருத்தில் கொள்ள மாட்டோம், ஏனெனில் இது இந்த பாடத்திட்டத்தின் நோக்கத்தில் சேர்க்கப்படவில்லை.

4.5 அங்கீகாரம்()

மேலும் ஒரு முக்கியமான புள்ளி. HTTP நெறிமுறை அங்கீகாரத்தை ஆதரிக்கிறது. நெறிமுறை மட்டத்தில் சரி.

இப்போது இந்த அணுகுமுறை கிட்டத்தட்ட பயன்படுத்தப்படவில்லை, ஆனால் சுமார் 20 ஆண்டுகளுக்கு முன்பு இது பொதுவானது. Http கோரிக்கை இப்படி இருந்தது:

http://username@example.com/

அல்லது இப்படியும்:

http://username:password@example.com/

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

Authenticator auth = new Authenticator() {
    @Override
    protected PasswordAuthentication getPasswordAuthentication() {
    return new PasswordAuthentication(
     "username",
        "password".toCharArray());
    }
};

HttpResponse<String> response = HttpClient.newBuilder()
  .authenticator(auth).build()
  .send(request, BodyHandlers.ofString());

இது மிகவும் சுவாரஸ்யமானது! “password"அது சொல்லும் குறியீட்டிற்கு பதிலாக ஏன் தெரியுமா "password".toCharArray()?

ஏனெனில் கட்டமைப்பாளரின் இரண்டாவது அளவுரு PasswordAuthentication அல்ல String, ஆனால் CharArray.

இரண்டாவது அளவுரு ஏன் இல்லை String, இல்லையா CharArray?

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

ஆனால் அதே நேரத்தில், கடவுச்சொல்லை பாதுகாப்பற்ற HTTP நெறிமுறையில் பாதி உலகம் முழுவதும் அனுப்ப முடியும் :) :) :)

சரி. உலகம் முழுமையடையாது.

கீழே உள்ள இணைப்புகளில் இந்த தலைப்பைப் பற்றி மேலும் படிக்கலாம்:

HTTP அங்கீகாரம்

HTTP அங்கீகாரத்தைப் புரிந்துகொள்வது

கருத்துக்கள்
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION