JavaScript - API(response data, REST API, contnet-type 등)

json

json이란

fetch('https://jsonplaceholder.typicode.com/users')
	.then((response) => response.text())
	.then((result) => { console.log(result); });

위 코드로 request를 보내면, html이 아닌 다른 종류의 데이터가 출력된다.
이 것이 json포맷이다.
어떤 정보를 나타낼 때에 보통 json포맷을 선택한다.
JavaScript Object Notation 의 줄임말로
정보를 교환할 때 사용하기 위해서 만들어졌다.
자바스크립트 문법을 빌려서 만들어진 데이터 포맷이다.
자바스크립트로부터 비롯되었지만, 탄생목적은 언어나 환경에 종속되지 않고, 언제 어디서는 사용할 수 있는 데이터 포맷이 되는 것이었다.

자바스크립트 객체 표기법과 json문법의 차이점

JSON에는 프로퍼티의 이름과 값을 표현하는 방식에 제한이 있다.
JSON에서는 각 프로퍼티의 이름을 반드시 큰따옴표(")로 감싸줘야한다.
JSON에서는 값이 문자열인 경우, 큰따옴표를 사용해야 한다.
JSON에는 표현할 수 없는 값들이 있다.
undefined, NaN, Infinity등의 자바스크립트 문법에서만 유효한 개념은 JSON에서는 나타낼 수 없다.
JSON에는 주석을 추가할 수 없다.
JSON은 코드가 아니라 데이터 포맷이기 때문에 주석을 사용할 수 없다.

JSON데이터를 객체로 변환하기

JSON은 response를 받을 당시에는 string이다.
하지만 자바스크립트 객체로 변환이 가능하다.

// json string을 객체로 변환
fetch('https://jsonplaceholder.typicode.com/users')
	.then((response) => response.text())
	.then((result) => { const users = JSON.parse(result)});

// json객체의 길이와 각 사용자의 이름 출력
fetch('https://jsonplaceholder.typicode.com/users')
	.then((response) => response.text())
	.then((result) => { 
			const users = JSON.parse(result);
			console.log(users.length);
			users.forEach((user) => {
				console.log(user.name);
			})
		});

string타입의 JSON데이터를 실제 자바스크립트 객체로 변환하는 것을 Deserialization, 역직렬화 라고 한다.
반대로 자바스크립트 객체를 string타입의 JSON데이터로 변환하는 것은 Serialization 직렬화이다.

request

request의 종류

데이터 조회
데이터 추가
데이터 수정
데이터 삭제

request에 존재하는 method를 보면 어떤 종류의 request인지 알 수 있다.

데이터 조회 > GET > GET Request
데이터 추가 > POST > POST Request
데이터 수정 > PUT > PUT Request
데이터 삭제 > DELETE > DELETE Request

각각의 메서드에 대해서 서버는 그에 맞는 데이터조작을 수행한다.

[ http 메서드에 관한 정리는 여기서 확인하기 https://develocal.tistory.com/91 ]

request의 구성

1. head

request에 대한 부가정보가 들어있다.
method값도 여기에 들어있다.
크롬브라우저 > 개발자모드 > Network탭 > Headers탭 의 RequestHeaders
header란 head안에 존재하는 하나하나의 key와 값의 한 쌍을 의미한다.

몇 가지의 header를 자세히 보면,

- :method: GET

방금 배운 method값을 확인할 수 있다.

- :path

url배울 때 배운 path를 확인할 수 있다.

- user-agent

request를 보낸 브라우저와 그것이 설치된 운영체제의 정보를 확인할 수 있다.

만약 서버에서 사용자들의 웹브라우저 정보를 수집한다면, 이 헤더의 값을 수집하면 되겠다.

각 header들의 맨앞에 ':' 콜론이 붙은 것(method, path)은 가상헤더로 표현했기 때문이다.

2. body

실제 데이터를 담는 부분.
GET, DELETE Request에서는 보낼 데이터가 없으므로 보통 필요 없다.
크롬브라우저 > 개발자모드 > Network탭 > Headers탭 의 Request Payload에서 body를 확인할 수 있다.
크롬브라우저 > 개발자모드 > Network탭 > Response탭 에서는 서버로부터 받은 response데이터를 확인할 수 있다.

Request 보내기

1. GET Request

// 전체 직원 조회
fetch('https://learn.codeit.kr/api/members')
	.then((response) => response.text())
	.then((result) => { console.log(result); });
    
// 특정 직원 조회
fetch('https://learn.codeit.kr/api/members/3')
	.then((response) => response.text())
	.then((result) => { console.log(result); });

2. POST Request

const newMember = {
    name: ' Jerry',
    email: 'jerry@codeitmall.kr',
    department: 'engineering',
}

fetch('https://learn.codeit.kr/api/members', {
    method: 'POST',
    body: JSON.stringify(newMember),
})
    .then((response) => response.text())
    .then((result) => { console.log(result)});

위 코드는 여태 봐 온 fetch함수와 다르게 파라미터를 하나 더 보내고있다.
이 아규먼트는 우리가 보낼 리퀘스트에 관한 설정을 적은 객체이고, '옵션 객체' 라고 부른다.
그리고 데이터를 보낼 때에는 JSON.stringify()함수를 사용해서 자바스크립트 객체를 string 타입의 JSON데이터로 변환 후 전달해야한다.
JSON.stringify()함수는 JSON데이터를 직렬화해주는 함수이다.

3. PUT Request

const member = {
    name: 'Alice',
    email: 'alice@codeitmall.kr',
    department: 'marketing',
}

fetch('https://learn.codeit.kr/api/members/2', {
    method: 'PUT',
    body: JSON.stringify(member),
})
    .then((response) => response.text())
    .then((result) => { console.log(result)});

4. DELETE Request

fetch('https://learn.codeit.kr/api/members/2', {
    method: 'DELETE',
})
    .then((response) => response.text())
    .then((result) => { console.log(result)});

Response

response의 구성

head

부가정보.
상태코드가 들어있다.(Network > Headers > Status Code 에서 확인 가능)

body

실제 데이터.
response받은 JSON데이터는 body에 들어있다.

response의 상태 코드

몇 가지만을 적어본다

100번대

서버가 클라이언트에게 정보성 응답(informational response)를 줄 때 사용되는 상태코드.

100 continue

클라이언트가 서버에게 계속 리퀘스트를 보내도 괜찮은지 물어봤을 때, 계속 보내도 괜찮다고 알려주는 상태코드.
예를들어, 클라이언트가 용량이 큰 파일을 리퀘스트 바디에 담아 업로드하려고 할 때 서버에게 미리 괜찮은지를 물어보는 경우가 있다고 할 때, 서버가 이 100번 상태코드의 리스폰스를 주면 그제서야 본격적인 파일 업로드를 시작한다.

101 switching protocols

클라이언트가 프로토콜을 바꾸자는 리퀘스트를 보냈을 때, 서버가 '그 프로토콜로 전환하겠다.' 하는 뜻을 나타낼때 쓰인다.

200번대

클라이언트의 리퀘스트가 성공 처리되었음을 의미하는 상태코드들이다.

200 OK

리퀘스트가 성공적으로 처리되었음을 포괄적으로 의미한다.

201 Created

리퀘스트의 내용대로 리소스가 잘 생성되었다는 뜻이다.
POST리퀘스트가 성공한 경우, 200번 대신 201번이 올 수도 있다.

202 Accepted

리퀘스트의 내용이 일단 잘 접수되었다는 뜻.
당장 리퀘스트의 내용이 처리된 것은 아니지만, 언젠가 처리할 것임.
리퀘스트를 어느정도 모아서 한번에 실행하는 서버인 경우 이런 응답을 줄 수 있다.

300번대

클라이언트의 리퀘스트가 아직 처리되지 않았고, 리퀘스트 처리를 원하면 클라이언트측의 추가적인 작업이 필요함을 의미한다.

301 moved Permanently

리소스의 위치가 바뀌었다.
이런 상태코드가 있는 리스폰스의 헤드에는 location이라는 헤더도 일반적으로 함께 포함되어있다.
그리고 그 헤더의 값으로 리소스에 접근할 수 있는 새 URL이 담겨있는데, 대부분의 브라우저는 만약 GET리퀘스트를 보냈는데 이 상태코드가 담긴 response를 받게되면, 헤드에포함된 location헤더의 값을 읽고, 자동으로 그 새 URL에 다시 시퀘스트를 보내는 동작(redirection)을 수행한다.

302 found

리소스의 위치가 일시적으로 바뀌었다.
지금은 아니지만 나중에는 현재 요청한 URL이 정상적으로 인식될 것이라는 뜻.
이 경우 보통 그 리스폰스의 헤드에 location헤더가 있고, 여기에 해당 리소스의 임시 URL값이 있다.
이 경우에도 대부분 브라우저들은 임시URL로 리다이렉션한다.

304 not modified

브라우저들은 보통 한 번 리스폰스로 받았던 이미지같은 리소스들을 내부에 저장한다.
그리고 서버는 해당 리소스가 바뀌지 않았다면, 리스폰스에 그 리소스를 보내지 않고 304번 상태코드만 헤드에 담아 보냄으로써 '네트워크 비용’을 절약하고, 브라우저가 저장된 리소스를 재활용하도록 한다.
사실 이 상태코드는 웹에서 캐시라는 주제에 대해 공부해야 이해 가능하다.

400번대

리퀘스트를 보내는 클라이언트 쪽에 문제가 있음을 의미한다.

400 bad request

리퀘스트에 문제가 있다. 내부내용의 문법에 오류가 있는 등.

401 unauthorized

신원이 확인되지 않은 사용자로부터 온 리퀘스트를 처리할 수 없다는 뜻.

403 forbidden

신원은 확인되었지만 해당 리소스에 대한 접근 권한이 없는 사용자라서 리퀘스트를 처리할 수 없다는 뜻

404 not found

해당 URL이 나타내는 리소스를 찾을 수 없다.

405 method not allowed

해당 리소스에 대해서 요구한 처리가 허용되지 않는다. 예를들면 delete request가 허용되지 않는데 delete request를 보낸 것.

413 payload too large

현재 리퀘스트의 바디에 들어있는 데이터 용량이 지나치게 커서 서버가 거부한다.

429 too many requests

일정 시간동안 클라이언트가 지나치게 많은 리퀘스트를 보냈다는 뜻.

500번대

서버쪽의 문제로 리퀘스트를 정상 처리할 수 없다.

500 internal server error

현재 알 수 없는 서버 내의 에러로 리퀘스트를 처리할 수 없다.

503 service unavailable

현재 서버 점검중이거나, 트래픽 폭주 등으로 인해 서비스를 제공할 수 없다는 뜻이다.

REST API

오늘날 많은 웹 개발자들이 Web API를 설계할 때 준수하기 위해 노력하는 일종의 가이드라인을 의미한다.
REST Architecture에 부합하는 API를 의미한다.
REST API를 사용하는 웹서비스는 RESTful 서비스라고 부른다.
REST API를 이해하기 위해서는 REST Architeture가 무엇인지 먼저 알아야한다.

REST Architecture

미국의 컴퓨터 과학자 Roy Fielding이 본인의 박사논문 'Architectural Styles and the Design of Network-based Software Architectures' 에서 제시한 개념.
웹이 갖추어야할 이상적인 구조로 REST architecture라는 개념을 제시했다.
여기서 REST는 Representational State Transfer(표현적인 상태 이전)의 줄임말로, 해석하면 '표현적인, 상태 이전'이라는 뜻이다.
웹을 거대한 프로그램이라고 생각하고, 웹서핑시 각각의 페이지를 웹이라는 프로그램의 새로운 상태를 나타내는 표현이라고 할 수 있겠다.

REST Architecture가 되기 위한 조건

1. Client-Server

clinet와 server가 독립적으로 운영되어야한다.

2. Stateless

client가 보낸 각 리퀘스트에 관해서 server는 그 어떤 맥락(context)도 저장하지 않는다.
모든 리퀘스트는 각각 독립적인 것으로 취급된다.
때문에 리퀘스트에는 항상 필요한 모든 정보가 담겨있어야 한다.

3. Cache

cache를 활용해 네트워크 비용을 절감해야한다.
server는 response에 client가 리스폰스를 재활용해도 되는지 여부를 담아 보내야한다.

4. Uniform Interface

4. 1) identification of resources
- 리소스로 URI를 식별할 수 있어야한다.
4.2) manipulation of resources through representations
- client와 server 둘 다 리소스를 직접 다루는게 아니라, 리소스의 '표현’을 다뤄야한다.
- 리소스와 리로스의 표현을 엄격하게 구분한다.
- 리소스 : 웹에 존재하는 특정 데이터를 나타내는 추상적인 개념
4.3) self-descriptive message
- '자기 설명적인' 이라는 뜻. client의 리퀘스트와 server의 리스폰스 모두 그 자체에 있는 정보만으로 모든 것을 해석할 수 있어야 한다.
4.4) hypermedia as the engine of application state
- server의 리스폰스에는 현재 상태에서 다른 상태로 이전할 수 있는 링크를 포함하고 있어야한다.
- 리스폰스에는 리소스의 표현, 각종 메타정보들 뿐 아니라, 계속 새로운 상태로 넘어갈 수 있도록 해주는 링크들도 포함되어있어야 한다.

5. Layered System

client와 server사이에는 프록시, 게이트웨이와 같은 중간 매개요소를 두고, 보안, 로드 밸런싱 등을 수행할 수 있어야한다.
이를 통해 client와 server사이에는 계층형 층들이 형성된다.

6. Code on Demand

client는 받아서 바로 실행할 수 있는 applet이나 script파일을 server로부터 받을 수 있어야한다.
이 조건은 optional한 조건으로, REST architecture가 되기위해 반드시 만족될 필요는 없다.

주요 규칙

많은 개발자들이 경험과 논의를 통해 형성된, 특히 강조하는 규칙 2가지를 자세히 보자.

1. URL은 리소스를 나타내기 위해서만 사용하고, 리소스에 대한 처리는 메소드로 표현해야한다.

예를들어, 새 직원 정보를 추가하기 위해서 request를 보낼 때, 아래의 두 경우를 확인해볼 수 있다.

// 규칙 준수
(1) 'https://learn.codeit.kr/api/members' URL로   
(2) 리퀘스트의 헤드에 POST 메소드를 설정하고,
(3) 리퀘스트의 바디에 새 직원 정보를 넣어서 보내면 된다

// 규칙 어김
(1)  'https://learn.codeit.kr/api/members/add' URL로
(2) 리퀘스트의 헤더에 GET 메소드를 설정하고,
(3) 리퀘스트의 바디에 새 직원 정보를 넣어서 보내면 된다

규칙을 준수한 request를 보면, URL은 리소스만을 나타내고, 리소스에대한 처리는 메서드 값인 POST로 나타냈기 때문에 규칙을 준수했다.
반면 규칙을 어긴 request를 보면, URL에서 리소스 뿐 아니라, 리소스에 대한 처리(add)까지도 나타내고있으며, 메소드 값은 GET(조회하는 메서드)을 설정했기 때문에 규칙을 어겼다.

2. 도큐먼트는 단수 명사로, 컬렉션은 복수명사로 표시한다.

리소스는 그 특징에 따라 여러 종류로 나뉘는데, 그 중 컬렉션과 도큐먼트 가 있다.
하나의 객체로 표현할 수 있는 리소스를 도큐먼트라고 부르고,
여러개의 도큐먼트를 담을 수 있는 리소스를 컬렉션 이라고 부른다.
자바스크립트객체로 봤을 때, 배열형식이 컬렉션, 객체형식이 도큐먼트라고 생각하면 될 것 같다.

https://jsonplaceholder.typicode.com/users/kang

위 URL은, 여러 User들 중에 kang인 사용자를 의미한다.

content-type

현재 리퀘스트 또는 리스폰스의 바디에 들어있는 데이터가 어떤 타입인지를 나타낸다.
서버가 request를 받았을 때, body의 데이터가 어떤 타입인지를 확인하는 절차가 사라지니 불필요한 비용 발생을 막을 수 있다.

content-type 종류

1. text인 경우

일반 텍스트 : text/plain
CSS 코드 : text/css
HTML 코드 : text/html
JavaScript 코드 : text/javascript ...

2. 이미지인 경우

image/bmp : bmp 이미지
image/gif : gif 이미지
image/png : png 이미지 ...

3. 오디오인 경우

audio/mp4 : mp4 오디오
audio/ogg : ogg 오디오 ...

4. 비디오인 경우

video/mp4 : mp4 비디오
video/H264 : H264 비디오 ...

5. 그 외

application/json : JSON 데이터
application/octet-stream : 확인되지 않은 바이너리 파일 ...
application/xml : xml

content-type 작성하기

fetch('https://learn.codeit.kr/api/members', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
  },
  body: JSON.stringify(newMember),
})
  .then((response) => response.text())
  .then((result) => { console.log(result); });

xml

//json
{
   "name":"Michael Kim",
   "height":180,
   "weight":70,
   "hobbies":[
      "Basketball",
      "Listening to music"
   ]
}

//xml
<?xml version="1.0" encoding="UTF-8" ?>
<person>
    <name>Michael Kim</name>
    <height>180</height>
    <weight>70</weight>
    <hobbies>
        <value>Basketball</value>
        <value>Listening to music</value>
    </hobbies>
</person>

xml은 시작태그와 끝태그, 그리고 그 사이의 값으로 나타낸다.
JSON이 2013년 표준화되고 활성화 되기 전까지 많이 사용되던 데이터 타입니다.
보통 xml을 쓸 때에는 스키마라는 별도의 문서롤 함께 사용한다.
스키마에는 각 조직, 기관 등에서 xml로 데이터를 나타낼 때 어떤 태그를 사용할 수 있고 각 태그의 의미가 무엇인지, 특정 태그는 어떤 타입의 값을 가질 수 있는지 등의 정보가 담겨있다.
따라서 xml은 데이터에 대한 엄격한 유효성(validity)검증에 특화된 데이터 포맷이라고 할 수 있다.
xml은 같은 양의 데이터를 표현하더라도 JSON에 비해 더 많은 용량을 차지하고, 가독성이 떨어지며 배우기 어렵다는 문제 등으로 입지가 좁아졌다.
openAPI나 이전에 작성된 코드들에는 여전히 xml타입의 데이터를 response하는 경우가 많으니 존재를 알아두면 좋다.

from 태그에서 사용되는 content-type타입

application/x-www-form-urlencoded 타입
multipart/form-data 타입

1. application/x-www-form-urlencoded 타입

<form></form> 폼태그.
폼태그를 사용하면 자바스크립트 코드 없이 오로지 HTML만으로도 리퀘스트를 보낼 수 있다.
오늘날에는 form태그를 사용하지 않고 자바스크립트 코드로 직접 사용자의 입력값을 취합해서 리퀘스트를 보내는 방법이 많이 사용되고 있지만 여전히 form태그만으로 리퀘스트를 보내는 방식도 쓰이고있기 때문에 알아두는 것이 좋다.
form태그는 기본적으로 application/x-www-form-urlencoded 타입의 데이터를 바디에 담아서 보낸다.

// json
{
  "id": 6,
  "name": "Jason",
  "age": 34,
  "department": "engineering"
}

// application/x-www-form-urlencoded 타입
id=6&name=Jason&age=34&department=engineering

프로퍼티의 이름과 값을 "이름 = 값" 형식으로 나타내고, 각각의 프로퍼티를 "&"기호로 연결하는 방식으로 데이터를 표현하는데, URL의 query부분에서 사용하는 방식과 같다.

html파일의 폼태그에 아래와같이 작성해주면 해당 데이터들도 리퀘스트를 보낼 때 header에 같이 담긴다.

<body>
  <div id="signup">
    <p id="title">CodeitShopping</p> 
    <form action="/upload" method="get" enctype="application/x-www-urlencoded">
      <div>
        <div><span class="label">email</span></div>
        <input class="input" type="text" id="email" name="email">
      </div>
      <div>
        <div><span class="label">password</span></div>
        <input class="input" type="password" id="password" name="password">
      </div>
      <div>
        <div><span class="label">nickname</span></div>
        <input class="input" type="text" id="nickname" name="nickname">
      </div>
      <div>
        <input id="submit-btn" type="submit" value="Sign Up">
      </div>
    </form>
  </div>
</body>

url encoding

url의 특수문자들은 아래와 같이 변환된다.

입력했던 실제 글자	표시된 내용
@	%40
!	%21
공백	+

이것은 application/x-www-form-urlencoded 타입의 특징이다.
URL encoding이라는 작업을 수행한 결과 특정 특수문자들 그리고 영어와 숫자를 제외한 다른 나라의 문자들을 이런식으로 변환한다.
URL encoding = Percent encoding

[

]

...

' '(공백)

%3A

%2F

%3F

%23

%5B

%5D

%40

%21

%24

%26

%27

...

%20 또는 +

이러한 문자들은 본래 용도가 따로 있는데, 본래 용도가 아닌 어떤 데이터를 나타내기 위해 사용되어야 한다면 이렇게 percent encoding을 해줘야한다.
URL해석에 대한 해석 오류를 방지하기 위함이다.
일단 URL표준에 따라 URL에서 어떤 문자들을 Percent encoding해야하는 경우가 있다는 것만 알고있자.

const urlencoded = new URLSearchParams();
urlencoded.append('email', 'tommy@codeit.kr');
urlencoded.append('password', 'codeit123!');
urlencoded.append('nickname', 'Nice Guy!');

fetch('https://learn.codeit.kr/api/members', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/x-www-form-urlencoded',
  },
  body: urlencoded,
})
  .then((response) => response.text())
  .then((result) => {
    console.log(result);
  });

위와 같이 URLSearchParams 라는 객체를 사용하면, 자동으로 값에 URL_encoding을 적용해주기 때문에 application/x-www-form-urlencoded 타입의 데이터를 fetch함수로도 손쉽게 보낼 수 있다.

2. multipart/form-data

여러 데이터를 하나로 묶어서 리퀘스트의 바디에 담아보내려고 할 때 사용되는 중요한 타입

<!-- form 태그만으로 멀티파트폼데이터 보내기 -->
<body>
  <div id="signup">
    <p id="title">CodeitShopping</p> 
    <form action="/upload" method="post" enctype="multipart/form-data">
      <div>
        <input id="image" type="file" name="file" accept="image/*">
        <div id="profile">
          <div id="plus">+</div>
        </div>
       </div>
      <div>
        <div><span class="label">email</span></div>
        <input class="input" type="text" id="email" name="email">
      </div>
      <div>
        <div><span class="label">password</span></div>
        <input class="input" type="password" id="password" name="password">
      </div>
      <div>
        <div><span class="label">nickname</span></div>
        <input class="input" type="text" id="nickname" name="nickname">
      </div>
      <div>
        <input id="submit-btn" type="submit" value="Sign Up">
      </div>
    </form>
  </div>
</body>

// 자바스크립트 코드만으로도 멀티파트폼데이터 보내기
const formData = new FormData();
formData.append('email', email.value);
formData.append('password', password.value);
formData.append('nickname', nickname.value);
formData.append('profile', image.files[0], "me.png");

fetch('https://learn.codeit.kr/api/members', {
  method: 'POST',
  body: formData,
})
  .then((response) => response.text())
  .then((result) => { console.log(result); });

ajax

웹브라우저가 현재 페이지를 그대로 유지한 채 서버에 리퀘스트를 보내고 리스폰스를 받아 화면에 변화를 줄 수 있게 해주는 기술이다.
Asynchronous JavaScript And XML 의 줄임말.
줄임말에 xml이 들어가는 것은 ajax기술이 만들어지던 당시 가장 인기있던 데이터타입이었기 때문이다.
비동기적으로 리퀘스트를 보내고 리스폰스를 받는데 기반이 되는 기술들의 집합을 말한다.
사용자가 보고있는 현재 화면에 영향을 미치지 않고, 별도로 백그라운드에서 작업을 처리할 수 있게 해준다.

const xhr = new XMLHttpRequest();
xhr.open('GET', 'https://learn.codeit.kr/api/members');
xhr.onload = function () {
  console.log(xhr.response);
};
xhr.onerror = function () {
  alert('Error!');
};
xhr.send();

위와 같이 XMLHttpRequest라고 하는 객체를 통해 Ajax통신을 했었지만, 요즘은 다른 방법을 사용한다.

이제 사용되지 않는 이유는

XMLHttpRequest 객체 이후에 등장한 fetch함수를 사용해 ajax통신이 가능하기때문.
그리고 fetch함수는 XMLHttpRequest 객체를 사용할 때에 비해 좀더 짧고 간단한 코드로 Ajax통신을 할 수 있다.
XMLHttpRequest 기반으로 더 쓰기 편하게 만들어진 axios라는 패키지가 존재하기 때문.

따라서 굳이 XMLHttpRequest 객체를 직접 가져다 쓸 필요성이 줄어들었다.

개발 실무에서도 fetch함수 또는 axios패키지를 사용한다.

외부패키지를 설치하고싶지 않은 경우에는 fetch를, 다양한 기능의 사용을 필요로 할때에는 axios패키지를 사용한다고 한다.

이렇게 비동기통신을 하는 서비스를 제작할 때에, 사용자의 경험을 고려해서

언제 아예 새로운 페이지를 로드할 것인지
언제 Ajax통신을 해서 현재 페이지 내에서 부드러운 변화를 줄 것인지

잘 결정하는 것이 중요하다.

저작자표시 비영리 변경금지

'JavaScript' 카테고리의 다른 글

JavaScript - async/await (1)	2023.10.13
JavaScript - 비동기 실행과 promise객체 (0)	2023.10.13
JavaScript - 웹과 통신 (0)	2023.10.13
JavaScript - 모듈화 (0)	2023.10.11
JavaScript - 배열 함수 및 유용한 내부 기능 (0)	2023.10.11