РеацтЈС: Након додавања Цхроме ЦОРС додатка, преузимање необрађеног одбијања (ТипеЕррор) није успело

Руковање АПИ грешкама у Реацт-у: изазови ЦОРС додатака

Када радите са АПИ-јима у РеацтЈС, програмери се често сусрећу са различитим изазовима у вези са преузимањем података, посебно када се баве АПИ-јима трећих страна. Један уобичајени проблем који се јавља је грешка „Необрађено одбацивање (ТипеЕррор): преузимање није успело“. Ова грешка се може јавити чак и када користите популарне АПИ-је као што је Свигги-јев АПИ за листу ресторана, који многи програмери користе за побољшање својих веб апликација.

У овом случају, додавање ЦОРС Цхроме екстензије може изгледати као одрживо решење за заобилажење рестриктивних смерница прегледача. Међутим, то може довести до нових компликација уместо да реши проблем. Ако користите ЦОРС додатак у свом развојном окружењу, а ваши АПИ захтеви не успеју убрзо након учитавања, могли бисте да наиђете на проблем где је додатак у сукобу са понашањем прегледача при руковању захтевима.

Разумевање начина управљања захтевима из више извора и решавања проблема ЦОРС грешке у РеацтЈС-у је од суштинског значаја за несметан развојни процес. АПИ-ји попут Свигги-ја често имају безбедносне слојеве, као што је ЦОРС, за контролу приступа неовлашћених клијената. Ова ограничења могу довести до грешака које треба правилно отклонити.

У овом водичу ћемо истражити зашто долази до ове грешке, посебно након додавања ЦОРС додатка у Цхроме. Такође ћемо разговарати о стратегијама за његово решавање док радите са Свигги АПИ-јем у вашем Реаговати апликације.

Објашњавање решења за ЦОРС проблеме у Реацт-у са Свигги АПИ-јем

У првом решењу креирали смо а Ноде.јс бацкенд који користи Екпресс да заобиђе ЦОРС проблем приликом преузимања података о ресторану из Свигги-јевог АПИ-ја. ЦОРС политика спречава прегледаче да упућују захтеве другом домену осим ако тај домен то не дозвољава. Креирањем једноставног сервера, можемо да делујемо као средњи слој између клијента и АПИ-ја, преузимајући податке на страни сервера и враћајући их на Реацт фронт-енд. Овај метод избегава ЦОРС грешке пошто захтев долази из истог порекла као и клијентска апликација.

Екпресс бацкенд поставља прилагођена заглавља, посебно Аццесс-Цонтрол-Аллов-Оригин, што омогућава нашем клијенту да затражи ресурсе без суочавања са ограничењима ЦОРС-а. Позив преузимања за Свигги-јев АПИ се врши на страни сервера, а подаци се враћају у ЈСОН формату. Овај приступ се често сматра сигурнијим и ефикаснијим у производним окружењима јер скрива АПИ кључеве или осетљиве информације. Штавише, употреба покушаја-хватања осигурава правилно руковање грешкама, приказујући поруке о грешкама које су прилагођене кориснику ако АПИ не одговори.

У другом решењу, мењамо захтев за преузимање на Реацт коду на страни клијента. Овај метод укључује додавање прилагођених заглавља у позив преузимања, осигуравајући да је захтев правилно форматиран пре него што стигне до АПИ-ја. Користимо Реацт-ове усеЕффецт кука за покретање АПИ позива када се компонента монтира. Асинц функција чека на АПИ одговор, претвара га у ЈСОН и обрађује грешке ако захтев не успе. Међутим, ово решење се и даље суочава са проблемима са ЦОРС-ом ако АПИ директно не дозвољава захтеве за више порекла из прегледача.

Коначно, у трећем решењу користимо услугу треће стране под називом ЦОРС-Анивхере. Ово је услуга средњег софтвера која привремено помаже да се заобиђу ограничења ЦОРС-а преусмеравањем АПИ захтева преко њиховог сервера. Иако ово решење може да ради у развојним окружењима, не препоручује се за производњу због безбедносних ризика и зависности од спољних услуга. Такође уводи додатне трошкове јер додаје додатни слој процесу преузимања података. Коришћење овог метода може бити згодно током фаза тестирања, али га треба избегавати у производњи из безбедносних разлога.

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;

Решавање проблема са ЦОРС-ом у АПИ захтевима

Један од основних разлога за грешку „Неуспешно преузимање“ у Реацт апликацији, посебно када се користе АПИ-ји трећих страна као што је Свигги, је ЦОРС (Унакрсно дељење ресурса) ограничења. ЦОРС је безбедносна функција која ограничава веб апликације да упућују захтеве на домен који се разликује од оног са којег су испоручене. У овом случају, Свигги АПИ одбија захтев јер потиче са другог домена (ваше Реацт апликације). Ово је посебно проблематично када преузимате податке из АПИ-ја који експлицитно не подржавају захтеве из више извора.

Уобичајено решење је коришћење проширења прегледача као што је „Аллов ЦОРС“ Цхроме екстензија. Међутим, таква проширења могу довести до недоследних резултата. То је зато што манипулишу подешавањима на нивоу прегледача која се не синхронизују увек правилно са АПИ захтевима. Ове додатке би идеално требало користити само за развој, а не у производним окружењима. За производњу, сигурнији и поузданији приступ био би коришћење позадинског прокси сервера који захтева податке у име ваше Реацт апликације, као што се види у решењима која су раније дата.

Још један аспект који треба узети у обзир је ефикасно руковање грешкама. Иако су проблеми са ЦОРС-ом чест узрок грешака „Неуспешно преузимање“, други фактори као што су нестабилност мреже, нетачни АПИ УРЛ-ови или застоји сервера такође могу довести до ове грешке. Дакле, важно је имплементирати робусно руковање грешкама у вашем коду, посебно када радите са АПИ-јима трећих страна. Одговарајући механизам за руковање грешкама ће помоћи у ефикаснијем отклањању грешака у проблему и пружити поруке прилагођене кориснику када нешто крене наопако.