ReactJS: Chrome CORS செருகுநிரலைச் சேர்த்த பிறகு, கையாளப்படாத நிராகரிப்பு (வகைப் பிழை) பெறுவதில் தோல்வி

எதிர்வினையில் API பிழைகளைக் கையாளுதல்: CORS செருகுநிரல் சவால்கள்

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

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

கிராஸ்-ஆரிஜின் கோரிக்கைகளை எவ்வாறு நிர்வகிப்பது மற்றும் சரிசெய்தல் ஆகியவற்றைப் புரிந்துகொள்வது CORS பிழைகள் ReactJS ஒரு மென்மையான வளர்ச்சி செயல்முறைக்கு அவசியம். Swiggy போன்ற APIகள், அங்கீகரிக்கப்படாத வாடிக்கையாளர்களிடமிருந்து அணுகலைக் கட்டுப்படுத்த, CORS போன்ற பாதுகாப்பு அடுக்குகளைக் கொண்டிருக்கும். இந்த கட்டுப்பாடுகள் சரியாக கவனிக்கப்பட வேண்டிய பிழைகளுக்கு வழிவகுக்கும்.

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

Swiggy API உடன் எதிர்வினையில் CORS சிக்கல்களுக்கான தீர்வுகளை விளக்குகிறது

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

எக்ஸ்பிரஸ் பின்தளமானது தனிப்பயன் தலைப்புகளை அமைக்கிறது, குறிப்பாக Access-Control-Allow-Origin, இது எங்கள் வாடிக்கையாளரை CORS கட்டுப்பாடுகளை எதிர்கொள்ளாமல் ஆதாரங்களைக் கோர அனுமதிக்கிறது. Swiggy இன் APIக்கான அழைப்பு சேவையகத்தின் பக்கமாக மாற்றப்பட்டது, மேலும் தரவு JSON வடிவத்தில் வழங்கப்படும். ஏபிஐ விசைகள் அல்லது முக்கியமான தகவல்களை மறைப்பதால், இந்த அணுகுமுறை உற்பத்திச் சூழல்களில் மிகவும் பாதுகாப்பானதாகவும் செயல்திறன் மிக்கதாகவும் கருதப்படுகிறது. மேலும், டிரை-கேட்ச்சின் பயன்பாடு சரியான பிழை கையாளுதலை உறுதிசெய்கிறது, API பதிலளிக்கத் தவறினால், பயனர் நட்பு பிழைச் செய்திகளைக் காண்பிக்கும்.

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

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

const express = require('express');
const fetch = require('node-fetch');
const app = express();
const port = 5000;

app.use((req, res, next) => {
  res.setHeader('Access-Control-Allow-Origin', '*');
  res.setHeader('Access-Control-Allow-Methods', 'GET');
  next();
});

app.get('/restaurants', async (req, res) => {
  try {
    const response = await fetch('https://www.swiggy.com/dapi/restaurants/list/v5?lat=23.1685786&lng=79.9338798');
    const data = await response.json();
    res.json(data);
  } catch (err) {
    res.status(500).json({ error: 'Failed to fetch restaurants' });
  }
});

app.listen(port, () => {
  console.log(`Server running on http://localhost:${port}`);
});

import React, { useEffect } from 'react';

const Body = () => {
  async function getRestaurants() {
    try {
      const response = await fetch(
        'https://www.swiggy.com/dapi/restaurants/list/v5?lat=23.1685786&lng=79.9338798',
        { headers: { 'Content-Type': 'application/json' } }
      );

      if (!response.ok) {
        throw new Error('Network response was not ok');
      }

      const data = await response.json();
      console.log(data);
    } catch (error) {
      console.error('Fetch error:', error);
    }
  }

  useEffect(() => {
    getRestaurants();
  }, []);
};

export default Body;

const Body = () => {
  async function getRestaurants() {
    try {
      const response = await fetch(
        'https://cors-anywhere.herokuapp.com/https://www.swiggy.com/dapi/restaurants/list/v5?lat=23.1685786&lng=79.9338798'
      );

      const data = await response.json();
      console.log(data);
    } catch (error) {
      console.error('Error fetching restaurants:', error);
    }
  }

  useEffect(() => {
    getRestaurants();
  }, []);
};

export default Body;

API கோரிக்கைகளில் உள்ள CORS சிக்கல்களைச் சரிசெய்தல்

ரியாக்ட் பயன்பாட்டில், குறிப்பாக ஸ்விக்கி போன்ற மூன்றாம் தரப்பு APIகளைப் பயன்படுத்தும் போது, ​​"பெறுவதில் தோல்வி" என்ற பிழைக்கான அடிப்படைக் காரணங்களில் ஒன்று CORS (கிராஸ்-ஆரிஜின் ரிசோர்ஸ் ஷேரிங்) கட்டுப்பாடுகள். CORS என்பது ஒரு பாதுகாப்பு அம்சமாகும், இது வலை பயன்பாடுகள் அவை வழங்கப்பட்ட டொமைனை விட வேறு டொமைனுக்கு கோரிக்கைகளை வைப்பதைக் கட்டுப்படுத்துகிறது. இந்த வழக்கில், Swiggy API கோரிக்கையை நிராகரிக்கிறது, ஏனெனில் இது வேறொரு டொமைனில் இருந்து (உங்கள் ரியாக்ட் ஆப்ஸ்) உருவானது. கிராஸ்-ஆரிஜின் கோரிக்கைகளை வெளிப்படையாக ஆதரிக்காத API களில் இருந்து தரவைப் பெறும்போது இது மிகவும் சிக்கலானது.

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

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