axios 인스턴스 생성과 헤더 설정

axios를 사용할 때, 서버 통신을 위해 해당 서버와 통신할 인스턴스를 만드는 사용되는 옵션들을 알아보자.

axios.create

axios.create라는 메서드를 통해 특정 서버에 대한 인스턴스를 생성할 수 있다.

export const client = axios.create({
   baseURL: "http://localhost:8080",
  timeout: 3000,
  headers: {
    "Cache-Control": "no-cache",
    "Content-Type": "application/json",
    "Access-Control-Allow-Origin": "*",
  },
  responseType: "json",
});

위와 같이 옵션이 설정되어있다고 했을 때 각 옵션에 대하여 살펴보자.

baseURL

baseURL : 통신할 서버 URL 기본값이다.
해당 값을 설정해놓으면 통신할 때마다 URL 기본값은 넣어주지 않아도 되며 기본 URL 뒤에 필요한 URL값만 할당해주면 된다.

BaseURL

client.get("/api/service/list")

client.post("/api/service/create")

client.patch("/api/service/update")

no BaseURL

axios.get("https://localhost:8080/api/service/list")

axios.post("https://localhost:8080/api/service/create")

axios.patch("https://localhost:8080/api/service/update")

위와 같이 baseURL을 넣어주지 않을 때에는 일일히 서버 기본 URL값을 입력해줘야하지만 baseURL에 기본 서버 URL를 할당해주면 필요한 API에 대한 URL만 입력해주면 된다.

headers

헤더를 설정해줄 수 있다.
위 예시에서 사용한 헤더 옵션을 살펴보자.

Cache-Control

Cache-Control : Cache-Control 옵션은 HTTP 요청과 응답에 대한 캐싱 동작을 제어하는 헤더이다. 캐싱은 이전에 수행한 요청 또는 응답 결과를 재사용하여 네트워크 성능을 향상시키고 대역폭을 줄일 수 있는 메커니즘이다.

Cache-Control은 다양한 값으로 구성될 수 있는데 위 예시에서는 no-cache 값으로 설정되어있다.

이는 서버 및 중간 캐시에 응답 결과를 캐시하지 않도록 한다.
이렇게 설정함으로써 항상 서버로부터 최신의 응답을 받을 수 있지만, 이는 캐싱의 이점을 제한하고 네트워크 성능에 영향을 줄 수 있다.

HTTP 헤더에 Cache-Control 옵션을 명시하지 않을 경우, Cache-Control의 기본값은 "public, max-age=0"이다.
기본값은 캐싱된 값을 재활용할 가능성이 있다.

• "public": 리소스를 공개 캐시에 저장할 수 있음을 나타냅니다. 즉, 중간 캐시 서버 등에 응답이 저장될 수 있습니다.

• "max-age=0": 캐시된 응답이 즉시 만료되도록 지정합니다. 따라서 매 요청마다 서버로부터 리소스를 다시 가져와야 합니다.

Content-Type

Content-Type 옵션은 HTTP 요청 또는 응답에서 전송되는 데이터의 형식을 나타내는 헤더이다다. 위 코드에서 "Content-Type": "application/json"으로 설정되어 있으므로, 요청의 본문 데이터나 응답의 데이터가 JSON 형식으로 전달됨을 나타낸다.

"Content-Type": "application/json"은 서버에 JSON 형식의 데이터를 전송하거나, 서버로부터 JSON 형식의 응답을 받을 때 사용된다.

JSON은 JavaScript Object Notation의 약자로, 데이터를 효과적으로 표현하기 위한 경량의 데이터이다. 이 형식은 대부분의 프로그래밍 언어에서 지원되며, 텍스트 형식으로 이루어져 있어 사람과 기계 모두 이해하기 쉽다.

Content-Type 값들

• "application/json": JSON 형식의 데이터를 나타냅니다.
• "application/xml": XML 형식의 데이터를 나타냅니다.
• "application/x-www-form-urlencoded": 웹 폼 데이터를 인코딩한 형식으로, 일반적으로 HTML 폼을 통해 전송되는 데이터를 나타냅니다.
• "multipart/form-data": 파일 업로드와 같은 멀티파트(form-data) 형식의 데이터를 나타냅니다.
• "text/plain": 일반 텍스트 데이터를 나타냅니다.
• "image/jpeg", "image/png", "image/gif": 이미지 파일을 나타내는 MIME 타입입니다.
• "audio/mpeg", "audio/wav", "audio/ogg": 오디오 파일을 나타내는 MIME 타입입니다.
• "video/mp4", "video/quicktime", "video/webm": 비디오 파일을 나타내는 MIME 타입입니다.

Access-Control-Allow-Origin

Access-Control-Allow-Origin 옵션은 Cross-Origin Resource Sharing (CORS) 기능을 사용할 때 클라이언트가 접근할 수 있는 출처(Origin)를 지정하는 헤더이다.

위 코드에서 "Access-Control-Allow-Origin": ""로 설정되어 있으므로, 서버는 모든 출처에서의 접근을 허용하고 응답을 반환할 수 있습니다. ""는 와일드카드를 의미하며, 모든 출처에서의 요청을 허용함을 나타낸다.

CORS는 웹 브라우저에서 실행되는 JavaScript 코드에서 다른 도메인의 리소스에 접근할 때의 보안 정책을 관리하는 메커니즘이다 보안 상의 이유로 브라우저에서는 동일 출처 정책(Same-Origin Policy)을 적용하여 스크립트가 다른 출처의 리소스에 접근하는 것을 제한한다. 그러나 CORS 정책을 이용하면 서버가 특정 출처에서의 접근을 허용할 수 있으며, 이를 통해 클라이언트의 요청을 처리하고 응답을 반환할 수 있다.

따라서 위 코드에서 "Access-Control-Allow-Origin": "*"은 서버가 모든 출처에서의 접근을 허용함을 의미한다. 이를 통해 클라이언트에서 해당 서버로의 요청이 CORS 정책에 따라 처리되고 응답을 받을 수 있게 된다.

서버에서 모든 출처에서의 접근을 허용하도록 설정해놨다고 했을 때 굳이 클라이언트측에서 위와 같이"Access-Control-Allow-Origin": "*"로 설정할 필요가 있는가?

• 서버에서 모든 출처에서의 접근을 허용한다면 클라이언트 측에서 명시적으로 "Access-Control-Allow-Origin": "*"을 설정해줄 필요는 없다. 서버가 모든 출처에서의 접근을 허용하는 경우, 클라이언트는 해당 서버로 요청을 보내고 서버의 응답을 받을 수 있다.
  "Access-Control-Allow-Origin": ""을 클라이언트 측에서 추가로 설정하는 것은 CORS 정책을 명시적으로 나타내는 것일 수 있으며, 일부 특정 상황에서는 필요할 수도 있다. 예를 들어, 서버 측에서의 설정이 잘못되어 헤더가 올바르게 전달되지 않을 경우 클라이언트 측에서 이를 보완하기 위해 해당 헤더를 추가로 설정할 수 있습니다. 하지만 일반적으로 서버에서 출처 접근을 허용하는 설정이 되어있다면 클라이언트에서 별도로 "Access-Control-Allow-Origin": ""을 설정할 필요는 없다.

responseType

responseType 옵션은 Axios 요청에 대한 응답(response)의 데이터 타입을 지정하는 데 사용되는 옵션이다.

Axios는 다양한 유형의 응답 데이터를 처리할 수 있다. 기본적으로 Axios는 responseType을 지정하지 않으면 응답 데이터를 문자열로 처리한다. 그러나 responseType을 설정하여 다른 데이터 유형으로 처리할 수 있다.

주로 사용되는 responseType 값은 다음과 같습니다:

• "arraybuffer": 응답 데이터를 ArrayBuffer로 처리합니다. 이는 주로 파일 다운로드 등 이진 데이터를 다룰 때 사용됩니다.
• "blob": 응답 데이터를 Blob 객체로 처리합니다. 마찬가지로 파일 다운로드 등 이진 데이터를 다룰 때 사용됩니다.
• "document": 응답 데이터를 HTML 문서로 처리합니다.
• "json": 응답 데이터를 JavaScript 객체(JSON)로 처리합니다. 이것이 가장 일반적으로 사용되는 옵션입니다.
• "text": 응답 데이터를 문자열로 처리합니다.
  예를 들어, 위의 코드에서 responseType: "json"으로 설정되어 있으므로, 응답 데이터는 JavaScript 객체(JSON)로 처리될 것입니다.

위 코드에서는 헤더 Content-type을 application/json으로 설정해놨으니 굳이 responseType은 json으로 설정해줄 필요없지 않을까?

• 실제로 Content-Type 헤더를 application/json으로 설정한 경우에는 responseType: "json"을 명시적으로 설정할 필요가 없다. Axios는 응답 데이터를 자동으로 JSON으로 처리한다.
  따라서, responseType: "json"을 제거해도 응답 데이터는 자동으로 JavaScript 객체(JSON)로 처리될 것이다. 이렇게 설정 변경을 통해 코드를 더 간결하게 유지할 수 있다.

timeout

timeout 옵션은 Axios 요청의 타임아웃을 지정하는 데 사용되는 옵션이다. 타임아웃은 서버로부터 응답을 받는 데 걸리는 시간을 제한하는 데 사용된다.

일반적으로, timeout 옵션은 밀리초 단위로 지정된다. 위의 코드에서는 timeout: 3000으로 설정되어 있으므로, 해당 요청은 서버로부터의 응답을 받기 위해 최대 3000 밀리초(3초)까지 대기하게 된다. 만약 응답이 3초 이내에 도착하지 않으면, 요청은 타임아웃으로 간주되고 실패 처리된다.

타임아웃 설정은 일반적으로 서버가 응답을 처리하는 데에 시간이 오래 걸리거나 네트워크 연결이 불안정한 경우 유용하다. 이를 통해 요청이 오래 걸리거나 무한히 대기하지 않고 제한된 시간 내에 응답을 받을 수 있다.

참고로, timeout 옵션을 0으로 설정하면 요청이 무기한 대기하게 된다. 이는 요청에 대한 타임아웃을 비활성화하는 효과가 있다.

timeout 이슈
회사 프로젝트에서 위와 같이 timeout을 3초로 설정해놨을 때, 계속해서 타임아웃이 된 경험이 있었다.
엑셀 파일 데이터들을 프로젝트 데이터로 등록할 때 , 1000개 정도의 데이터를 일괄적으로 등록하려하니 서버로 보낼 post 요청이 오래걸리는 이슈였다.
이를 위해 위 설정에서 timeout을 안정적으로 15초로 설정해두었다.
이러한 경우가 있을 수 있으니 안정적으로 10초에서 15초로 설정해두는 것이 좋을 것 같다.