[FE] 웹&앱 연합 스터디

Notice

Recent Posts

Recent Comments

Link

« 2024/12 »
일	월	화	수	목	금	토
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30	31

Tags more

Archives

Today

Total

관리 메뉴

wa_ter_ve

[FE] 웹&앱 연합 스터디 본문

공부/GDG

[FE] 웹&앱 연합 스터디

수win 2024. 11. 18. 10:25

📌 세션 & 쿠키 (Session & Cookies)

🔍 세션(Session)

: 서버가 일정시간 동안의 사용자 요청을 하나의 상태로 보고, 해당 상태를 유지 및 추적하는 방식.
(방문자가 웹 서버에 접속된 상태 → 세션)

클라이언트의 IP 주소로 각 클라이언트 식별이 불가하기에,
서버에서는 클라이언트를 식별하는 용도로 session ID를 사용.

특징
- 각 클라이언트에 고유 ID를 부여해, 서버가 ID를 통해 클라이언트를 구분할 수 있도록 도움.
- 서버는 각 클라이언트의 정보를 저장하여, 각 요청들의 세션 정보를 유지.
- 서버 메모리에 세션을 저장하므로 서버 용량에 영향을 받음. 사용자 증가시 메모리 사용량 증가.
- 세션은 서버 측에서 클라이언트의 데이터를 직접 관리하기 때문에 보안성 높음.
- 세션 ID는 쿠키를 통해 서버와 클라이언트 간 전달됨.

⬇️⬇️⬇️

🍪 쿠키(Cookies)

클라이언트 측에서 데이터 저장을 위해 사용하는 작은 데이터 조각. (세션 관리 기능)

특징
- 쿠키는 클라이언트 측에 저장됨.
- 서버가 클라이언트의 요청을 받는 경우마다, 해당 클라이언트에 저장된 쿠키를 전송.
- 클라이언트가 서버에 데이터 요청 시, 그 쿠키를 포함하여 요청을 전송.
- key-value 쌍의 형태로 저장됨. (ex. session_id = abc123 )
- 요청 시, 서버~클라이언트 간 자동으로 전송됨.

📌 동작 과정

1. 웹 브라우저가 서버에게 요청
2. 서버는 새 session ID 생성 및 쿠키 생성 후, session ID는 쿠키에 담기고
3. 이 쿠키는 http 상태 코드에 담겨 웹 브라우저에 전송됨.

서버가 보낸 http 상태 코드에 쿠키가 포함되어 있으면,

웹브라우저는 해당 서버에 요청을 보낼 때마다, 해당 쿠키를 request에 포함함.

🚧 HTTPOnly 쿠키 - (Web)

HTTPOnly 설정이 되어있는 쿠키는 클라이언트측(Javascript)에서 접근 불가능하여, 쿠키를 수정하거나 조작할 수 없음.

즉, 오직 서버만이 쿠키에 접근 가능.

→ XSS (Cross-Site Scripting) 공격 방지.
공격자가 악성 스크립트를 이용해 사용자의 쿠키를 탈취하는 공격.
HttpOnly 속성이 설정된 쿠키는 Javascript에서 접근 불가능하므로 해당 공격으로부터 세션 쿠키를 보호 가능.

→ CSRF(Cross-Site Request Forgery) 공격 방지.
사용자가 인증된 웹 사이트 상태에서 사용자의 권한을 도용해 서버에 요청을 보내는 공격.
HTTP Only 설정을 통해 JavaScript에서 쿠키를 읽지 못하게 하면, CSRF 공격을 보다 어렵게 만들 수 있음.
주로 쿠키에 포함된 인증 정보를 이용한 공격이므로, 방어를 위해서는 SameSite 쿠키 속성도 함께 사용.

HttpOnly 쿠키 설정 예시
- ↓ 서버 측 코드 (Node.js)

const express = require('express');
const app = express();

app.get('/set-cookie', (req, res) => {
  res.cookie('session_id', 'abc123', { httpOnly: true, secure: true }); 
    // httpOnly: true 설정을 통해 Javascript(클라이언트) 접근 불가능 하도록.
    // secure는 HTTP 연결에서만 전송되도록 하여 보안 강화.
  res.send('Cookie has been set!');
});

app.listen(3000, () => {
  console.log('Server is running on port 3000');
});

SameSite 쿠키 속성

- HttpOnly와 SameSite 속성을 설정하면, XSS와 CSRF 공격을 동시에 방지 가능.

res.cookie('session_id', 'abc123', {
  httpOnly: true,
  secure: true,
  sameSite: 'Strict' // -> SameSite 속성으로 CSRF 공격 방지
});

📌 HTTP

: HTTP (Hypertext Transfer Protocol)
클라이언트 - 서버 간 데이터 전송을 위해 정의된 프로토콜.
요청(request) & 응답(response) 방식을 통해 데이터를 전달.
각 응답과 요청은 header와 body로 구성.

▷ HTTP 요청 (Request)

클라이언트 → 서버

<HTTP Method> <URL> <HTTP Version>
<Headers>
<Body (Optional)>

<HTTP Method> - 클라이언트가 요청하는 작업에 대해 정의. (GET, POST, PUT, DELETE 등)
<URL> - 요청하는 리소스 주소. 서버 요청 처리를 위해 구체적인 엔드포인트 지정.
<Headers> - 메타 정보 및 요청 상태를 서버에게 알림.
<Body (Optional)> - 서버에 전송할 데이터 내용. (Get 요청은 body 없음 / POST&PUT 요청은 body 포함 가능.)

HTTP 요청 예시

GET 요청

GET /api/user?id=123 HTTP/1.1
Host: example.com
Accept: application/json

* /api/user?id=123: 서버의 엔드포인트 및 쿼리 파라미터

* Accept: 클라이언트가 응답 받을 데이터의 유형

POST 요청

POST /api/user HTTP/1.1
Host: example.com
Content-Type: application/json
Authorization: Bearer token_here

{
  "name": "수인",
  "age": 23,
  "city": "SEOUL"
}

* Content-Type: request body의 데이터 형식. (위 예시에는 JSON 형식으로 정의)

* Authorization: 인증 정보. (위 예시에는 토큰을 사용한 인증)

* { ~~~ }: body로 서버에 전송할 데이터 내용. (주로 JSON, XML, 텍스트와 같은 형식으로 전송.)

▷ HTTP 응답(Response)

서버 → 클라이언트

<HTTP Version> <Status Code> <Status Message>
<Headers>
<Body (Optional)>

<HTTP Version> - 응답에 이용되는 HTTP 버전
<Status Code> - 상태 코드
<Status Message> - 상태 코드에 대한 메시지
<Headers> - 응답에 대한 메타 정보 포함. (ex. Content-Type, Content-Length, Set-Cookie )
<Body (Optional)> - 서버에 전송할 데이터 내용. (Get 요청 - 데이터 반환 / POST 요청 - 성공 결과 반환)

HTTP 응답 예시

200 OK 응답

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 55

{
  "name": "수인",
  "age": 23,
  "city": "SEOUL"
}

* 200 OK: 요청이 성공적으로 처리됨.

404 Not Found 응답

HTTP/1.1 404 Not Found
Content-Type: text/html
Content-Length: 138

<html>
  <body>
    <h1>404 Not Found</h1>
    <p>The requested resource could not be found on this server.</p>
  </body>
</html>

* 404 Not Found: 요청한 URL을 서버에서 찾을 수 없음.

* Content-Type: 응답 데이터 형식 (위 예시에서는 HTML)

* Body: 오류 메시지 및 데이터가 body에 포함됨.

✔️

클라이언트가 GET 요청을 보내면, 서버는 해당 리소스를 조회하여 응답 본문에 데이터를 포함하여 반환함.

응답 본문에 포함된 데이터는 웹 페이지, JSON 객체 등으로 표현.

📮 HTTP 상태 코드

상태 코드(response status code) ?

: 클라이언트와 서버 간의 통신 상태를 나타내는 표준화된 코드의 모음.
클라이언트가 요청을 보냈을 때 응답되는 상태 코드를 통해 서버에게 보낸 요청이 어떻게 처리되었는지 파악 가능.

HTTP response 첫줄에 표시.
(예시 ↓)

HTTP/1.1 200 OK
Date: Sun, 21 Apr 2013 15:12:46 GMT
Server: Apache
Connection: close
Content-Type: text/html; charset=ISO-8859-1
Content-length: 115

<html>
<head>
<title>
A Sample HTML file
</title>
</head>
<body>
The rest of the document goes here
</body>
</html>

🟢 HTTP/1.1
=> 프로토콜 버전

🟡 200 OK
=> 상태 코드

1xx: 정보 응답
2xx: 성공 응답
3xx: redirection
4xx: 클라이언트 요청 오류
5xx: 서버 오류

❤️ 1XX - 정보 응답

100 Continue
: request body 전송을 계속해도 된다는 의미.
서버가 request header의 metadata를 받은 직후, 대용량의 request body를 받기 직전에 보내는 응답 코드.
부담이 될 수 있는 대용량의 request body를 보내고 나서도 거부 당하지 않고 계속 전송해도 되는지 미리 확인을 받기 위한 용도의 응답 코드.

101 Switching Protocol
: 클라이언트가 보낸 Upgrade 요청 헤더에 대한 응답으로 보내지며,
서버에서 프로토콜을 변경할 예정임을 클라이언트에게 알림.
(ex. HTTP 프로토콜에서 WebSockets 프로토콜로 변경)

102 Processing (deprecated)
: 서버가 요청을 수신하고 이를 처리는 하고 있지만,
아직 제대로 된 응답을 알려줄 수 없음을 클라이언트에 알림.

103 Early Hints
: 주로 Link 헤더와 함께 사용되며
서버가 응답을 준비하는 동안, 사용자 에이전트가(user agent) 사전 로딩(preloading)을 시작할 수 있도록 함.

💛 2XX - 성공 응답

200 OK
: 요청이 성공적으로 처리됨.
response body에는 요청된 데이터가 존재.

201 Created
: POST request에 의해 서버에 새 리소스가 생성됨. (주로 POST 또는 PUT 요청 응답)
새 리소스에 대한 URL이 response body에 존재.

202 Accepted
: 요청은 수신하였으나, 아직 처리가 완료되지 않음.

203 Non-authoritative Information
: 이 응답은 요청된 서버가 아닌, 네트웍 통신 중간의 캐시 역할을 하는 누군가가 보낸 응답.
따라서 이 응답은 최신 버전이 아닐 수 있음.

204 No Content
: 요청이 성공적으로 처리되었으나, 응답으로 보낼 자료 없음.

205 Reset Content
: 요청이 성공적으로 처리되었으나, 응답으로 보낼 자료 없음.
(새로고침 등을 통해 새 내용을 확인하라고 알림)

206 Partial Content
: 서버가 GET 요청의 일부만 성공적으로 처리함.
response body에는 요청된 일부 자료만 존재.
(클라이언트가 데이터를 이어받기를 시도하면, 서버는 request header의 Range 항목에 명시된 부분부터 전송.)

💚 3XX - redirection

300 Multiple Choices
: 요청이 여러 응답이 가능할 경우, 하나를 골라서 보내라고 클라이언트에게 선택지를 반환.

301 Moved Permanently
: 요청된 자료의 URL이 변경되었음을 알림.
(변경된 URL은 response header의 Location 항목에 존재.)

302 Moved Temporarily
: 요청된 자료의 URL이 임시로 변경되었음을 알림.
(새 URL은 response header의 Location 항목에 존재.)
재요청 시 원래의 URL로 요청해야 함.

303 See Other
: 클라이언트 요청에 따른 작업을 위해서 다른 URL 필요할 때 서버가 클라이언트에게 전송.
(살펴볼 URL은 response header의 Location 항목에 존재.)

304 Not Modified
: 클라이언트가 보낸 요청에 request header 항목 'If-Modified-Since: 시각' 이 있는 경우, 그 시각 이후로 변경된 경우에만 데이터를 요청.
변경되지 않았으면 데이터는 보낼 필요없고, 304 Not Modified 상태 코드만 전송.
주로, 캐시 역할을 하는 proxy가 해당 요청을 전송.

307 Temporary Redirect
: 302과 동일한 의미 (=요청된 자료의 URL이 임시로 변경되었음을 알림.)
+ 클라이언트가 보낸 HTTP 메소드도 변경 불가.
(302와 다른 점: 기존의 HTTP 메소드 유지하며 redirection)

308 Permanent Redirect
: 301과 동일한 의미 (=요청된 자료의 URL이 변경되었음을 알림.)
+ HTTP 메소드도 변경 불가.
(301과 다른 점: 기존의 HTTP 메소드 유지하며 redirection)

🩵 4XX - 클라이언트 요청 오류

400 Bad Request
: HTTP request에 오류가 있어서, 서버가 이해할 수 없음.

401 Unauthorized
: 접근 권한이 없는 URL 요청에 대한 응답 코드. (→ Authorization 에러)

403 Forbidden
: 인증(Authorization) 문제가 아닌, 다른 문제로 접근이 금지된 경우에 대한 응답 코드. (→ Authentification 에러)
클라이언트가 인증되어도, 접근이 금지되는 경우.
(ex. 네트워크 트래픽 초과, IP 차단, 특정 리소스 제한, 지역 제한 등)

404 Not Found
: 요청된 URL에 대한 자료를 찾을 수 없다는 응답 코드.

405 Method Not Allowed
: 클라이언트가 요청한 HTTP 메서드(POST, PUT, DELETE 등)가 서버에서 허용되지 않는 경우 반환.
서버가 특정 리소스에 대해 해당 메서드를 지원하지 않는다는 의미.
(ex. API 엔드포인트가 GET 요청만을 허용하고 있을 때, 클라이언트가 POST 요청을 보내면 나타나는 응답.)

406 Not Acceptable
: 클라이언트 요청 헤더의 Accept 항목에 MIME 타입(application/json, text/html, application/xml 등)에 대해,
서버가 데이터 제공이 불가능한 경우 반환.
(ex. 서버는 오직 JSON 형식(application/json)만을 제공할 수 있는데, 클라이언트는 Accept: text/html을 요구한 경우 )

408 Request Timeout
: 클라이언트 요청 완료(마지막 빈줄)까지 너무 오래걸려서 시간 제한을 초과했음을 알림.

410 Gone
: 요청된 URL에 대한 자료가 존재하지 않음.
(서비스가 종료되었을 경우.)

411 Length Required
: 클라이언트가 요청 시, request header에 Content-length 항목을 포함하지 않아, 서버가 처리 불가능한 경우.

413 Request Entity Too Large
: reqeust body가 서버가 허용하는 최대 크기를 초과.
(용량이 큰 파일을 업로드 할 때 발생하는 에러)

414 Request URI Tool Long
: URL이 너무 길 때 발생하는 에러.

415 Unsupported Media Type
: 서버가 지원하지 않는 미디어 포맷을 요청한 경우.

416 Requested Range Not Satisfiable
: 클라이언트 요청 헤더의 Range 필드가 서버의 리소스 범위를 벗어난 경우.
*(Range header: 클라이언트가 특정 데이터 부분만 받도록 요청할 때 사용됨)

417 Expection Failed
: 클라이언트 요청 헤더의 Expect 필드가 서버에서 처리 불가능 또는 지원되지 않는 경우.
*(Range header: 특정 조건에 부합할 때만 서버가 요청을 처리하도록 할 때 사용됨)

💜 5XX - 서버 오류

500 Internal Server Error
: 서버 내부의 알 수 없는 에러.

502 Bad Gateway
: 프록시나 게이트웨이 역할을 하는 서버가 클라이언트의 요청을 처리하기 위해,
다른 서버로부터 유효하지 않거나 예상하지 못한 응답을 받았을 경우.
*(Proxy/Gateway Server: 클라이언트와 실제 리소스를 제공하는 서버 사이에 위치하여 요청과 응답을 중계.)

503 Service Unavailable
: 서버가 잠시 응답 불가능.

504 Gateway Timeout
: 프록시나 게이트웨이 서버가 백엔드 서버로부터 응답을 기다리는 동안,
시간이 초과되어 해당 서버에서 요청을 처리할 수 없는 경우.
(ex. 네트워크 지연, 백엔드 서버의 과부하, 서버 다운 등)

505 HTTP Version Not Supproted
: 클라이언트 요청의 HTTP 버전을 서버에서 지원하지 않음.

511 Network Authentication Required
: 클라이언트가 Network 엑세스를 얻기 위한 인증이 필요.
(ex. KT WIFI 인증이 필요한 경우)

⚙️ API 통신

💭 API?

= Application Programming Interface
프로토콜 집합을 사용하여 두 소프트웨어 구성 요소가 서로 통신할 수 있게 하는 메커니즘.
(ex. 모바일 날씨앱은 API를 통해, 기상청의 데이터 시스템과 연결되어 날씨 정보를 표시.)

왜 사용할까?

- 개발 및 관리가 효율적
해당 서비스가 어떻게 구현되었는지 자세히 몰라도 가져와서 사용이 가능함.
따라서, 시간과 비용을 줄여 더욱 효율적으로 개발할 수 있도록 도와줌.
- 유연성 및 확장성
신규 개발에 확장성이 좋음. 타사 서비스와 연계하여 새로운 앱/웹을 개발 가능하여,
더욱 다양하고 새로운 서비스들을 개발할 수 있는 환경이 구축됨.

🎈 '클라이언트 - 서버' 통신

- API에 대해 이해하기 위해서는
우리가 웹 또는 앱을 이용하는 경우에 데이터 처리가 어떻게 이루어지는지,
클라이언트와 서버 간의 데이터 통신이 어떤 과정을 거치는지 이해해야함.

손님 - 웹 브라우저(클라이언트)
서버 - 바리스타
데이터베이스 - 창고
데이터 - 원두

1. (손님이 직접 원두를 구해 커피를 만들지 않고 바리스타에게 주문.)
클라이언트가 원하는 데이터를 직접 데이터베이스에 접근하지 않고 서버에게 요청.

2. (바리스타는 주문받은 원두를 이용해 커피를 제작.)
서버는 데이터베이스에서 해당 데이터를 찾아서 꺼냄.

3. (제작한 커피를 해당 메뉴를 주문한 손님에게 전달.)
서버는 클라이언트에게 요청받은 해당 데이터를 전달.

◎ API 작동 방식 4가지 유형

SOAP API
(Simple Object Access Protocol)

- 단순 객체 접근 프로토콜 사용.
- XML을 사용하여 클라이언트와 서버 간 메시지 교환.
- 주로 HTTP, SMTP와 같은 프로토콜을 통해 데이터를 전달.
- 유연성이 떨어지며(엄격한 규칙), 보안, 트랜잭션 처리 등 추가적인 기능을 지원.
- 과거에 많이 사용되었음.
(ex. 강력한 보안과 트랜잭션 처리 기능을 요구하는 기업 환경에서 사용.)

RPC API
(Remote Procedure Call)

- 원격 프로시저 호출이라고 함.
- 클라이언트가 서버에서 제공하는 함수/프로시저 호출 완료 시, 서버가 클러이언트에게 출력 전송.
- 직관적이고 간단한 호출 방식이며, 동기적으로 동작함.
- 비동기 처리가 어려워 효율성이 떨어질 수 있음.
(ex. 분산 시스템에서 서버가 클라이언트 측으로 특정 작업을 원격 호출하는 경우 사용.)

Websocket API

- JSON 객체를 사용하여 데이터를 전달하는 최신 웹 API.
- 클라이언트앱과 서버 간 양방향 통신 지원.
- 서버 연결된 클라이언트에 콜백 메시지를 전송 가능하여 REST API 보다 상대적으로 효율적.

REST API
(Representational State Transfer)

- REST는 클라이언트가 서버 데이터에 액세스하는 데 사용할 수 있는 GET, PUT, DELETE 등의 함수 집합을 정의.
- 클라이언트와 서버는 HTTP를 사용하여 데이터를 교환.
- REST API의 주된 특징은 'Stateless' → 서버가 클라이언트의 상태를 저장하지 않음.
- 서버의 응답은 웹 페이지의 일반적인 그래픽 렌더링이 없는 일반 데이터.

→ 각 API 방식의 차이점 요약:

유형	특징	장점	단점	사용 예시
SOAP API	XML을 사용, 엄격한 규격	보안, 트랜잭션 처리 지원	무겁고 유연성이 떨어짐	기업 환경, 금융 시스템
RPC API	서버 함수 호출, 원격 프로시저 처리	간단하고 직관적	네트워크 지연, 비동기 처리 어려움	분산 시스템, gRPC
WebSocket API	양방향 통신, 실시간 데이터 푸시 가능	실시간 통신 효율적, 이벤트 푸시 가능	서버와 클라이언트 간 연결 유지 필요	채팅 앱, 실시간 주식 거래 시스템
REST API	HTTP 메서드(GET, POST 등), 무상태성 기반	간단하고 유연함, HTTP 프로토콜 사용	실시간 처리 어려움	웹 애플리케이션, 모바일 앱 통신

◎ API 보호

1. 인증 토큰
- 사용자에게 API 호출을 수행할 수 있는 권한 부여에 이용되는 시스템.
- 사용자가 자신이 누구인지 확인하고 해당 특정 API 호출에 대한 액세스 권한이 있는지 확인.
(ex. 웹 서버에 로그인 시 해당 웹의 클라이언트는 보안 엑세스를 위해 인증 토큰을 사용.)

2. API 키
- API를 호출하는 프로그램 or 애플리케이션을 확인하는 기능 수행.
- 애플리케이션을 식별하고 애플리케이션에 특정 API 호출을 수행하는데 필요한 액세스 권한이 있는지 확인.
- 인증 토큰에 비해 상대적으로 안전성이 떨어지지만, 사용량에 대한 데이터 수집을 위해 API 모니터링 허용.

◎ Open API

카카오
https://developers.kakao.com/product

네이버
https://developers.naver.com/products/intro/plan/plan.md

구글
https://console.cloud.google.com/apis/library?supportedpurview=project&pli=1&inv=1&invt=Abhysw

💭 CRUD?

Create (POST) - 새로운 데이터 생성 시 사용. 서버에 데이터 제출.
(ex. 사용자가 회원가입 폼을 제출하는 경우, 해당 데이터를 클라이언트가 서버에게 전송하여 서버가 데이터베이스에 데이터를 저장하는 작업.)
Read (GET) - 데이터 읽을 때 사용. 조회 기능만. 서버에서 데이터 수정하지 않음.
(ex. 사용자 프로필 정보 조회 시, 클라이언트가 서버에게 GET 요청을 보내 해당 데이터베이스를 조회 가능.)
Update (PATCH) - 기존의 데이터를 수정 시 사용. 전체 데이터 말고, 일부 데이터 수정 시 PATCH 사용.
(ex. 사용자가 이메일을 업데이트 할 때 서버에 PATCH 요청을 전송.)
Delete (DELETE) - 데이터 삭제 시 사용.
(ex. 사용자가 특정 게시물 삭제 또는 계정 탈퇴를 하는 경우 DELETE 요청을 서버에 전송.)

📌 HTTP 응답 메소드 (HTTP request method)

GET	자료 조회 요청
POST	새 자료 등록 요청
PATCH	기존 자료 수정 요청
DELETE	자료 삭제 요청

- 주로 웹 서버에서는 GET, POST 방식 사용됨.
- 자료 조회 요청일 경우 GET 방식으로 요청.
- 자료 등록, 수정, 삭제 요청일 경우 POST 방식으로 요청.

GET 요청 ex.

GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 ...

* /index.html: 요청하는 리소스 (파일).
* Host: 요청하는 서버의 도메인 (www.example.com)
* User-Agent: 요청을 보내는 클라이언트(브라우저) 정보

POST 요청 ex.

POST /register HTTP/1.1
Host: www.example.com
Content-Type: application/json
Content-Length: 123

{
"username": "Sooin",
"password": "123456789"
}

* /register: 요청하는 리소스 (회원가입 API)
* Content-Type: 전송하는 데이터 형식
* Content-Length: 전송할 데이터의 길이

📌 API 통신 예제

무료 api 예제 제공 사이트
https://jsonplaceholder.typicode.com/

(Json 형식 데이터)
https://jsonplaceholder.typicode.com/posts

Json (JavaScript Object Notation)
: 텍스트 기반의 데이터 교환 형식.
- 주로, 웹 애플리케이션에서 데이터 전송 시 사용됨.
- 데이터의 가독성 향상을 위해 만들어진 표기법. 객체 형태 자바스크립트 표기법에 기반.
- Key : Value 형태로 이루어짐.

{
//  키 : 값
  "name": "수인",
  "age": 23,
  "city": "SEOUL",
  "fruits" : ["orange", "grape", "peach"]  // 배열
}

예시

● 클라이언트→서버 JSON 전송 (POST 요청)
const data = {
  name: "수인",
  age: 23
};

fetch('https://example.com/api', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json'
  },
  body: JSON.stringify(data)
})
.then(response => response.json())
.then(data => console.log(data));
● 서버→클라이언트 JSON 반환 (GET 요청)
fetch('https://example.com/api')
  .then(response => response.json())
  .then(data => {
    console.log(data);
    // JSON 응답 예시: { "name": "수인", "age": 23 }
  });
* response.json() : 서버 응답 body 데이터를 JSON 형식으로 변환.

* API 주소(URL)를 통해 API를 호출하면, 서버는 위와 같은 Json 데이터들을 전달해줌.

▷ axios 설치 (React)

yarn add axios

▷ JSON 서버 설치 (React)

설치
yarn add json-server@0.17.4

실행
json-server --watch db.json

🟠 axios

API 호출 작성위치
- 주로, 컴포넌트 파일 내부 또는 별도의 파일에 작성

◎ 새로운 프로젝트 만들고 App.tsx 파일에 아래 예제 코드 실습해보기

import { useState, useEffect } from 'react';
import axios from 'axios';
import './App.css';

function App() {
  const [posts, setPosts] = useState([]);
  const [newPost, setNewPost] = useState({ title: '', body: '', userId: 1 });

  // GET 요청 
  useEffect(() => { //useEffect를 통해 컴포넌트가 마운트될 때 자동으로 GET 요청 실행됨.
    axios.get('https://jsonplaceholder.typicode.com/posts')
      .then(response => {
        console.log(response.data);
        setPosts(response.data); // 데이터를 상태에 저장
      })
      .catch(error => {
        console.error('Error fetching data:', error);
      });
  }, []);

  // POST 요청
  const handlePost = () => { //버튼 클릭시 를 통해 컴포넌트가 마운트될 때 자동으로 GET 요청 실행됨.
    axios.post('https://jsonplaceholder.typicode.com/posts', newPost)
    // then/catch를 통한 응답 처리 확인
      .then(response => { 
        console.log(response.data);
        alert('Post created successfully');
      }) // 성공
      .catch(error => {
        console.error('Error creating post:', error); // 에러 핸들링(에러 메시지 표시)
      }); // 실패
  };

  return (
    <div>
      <h1>React Axios Example</h1>
      <h2>Posts</h2>
      <ul>
        {posts.map((post: any) => (
          <li key={post.id}>{post.title}</li>
        ))}
      </ul>

      <h2>Create New Post</h2>
      <input
        type="text"
        placeholder="Title"
        value={newPost.title}
        onChange={(e) => setNewPost({ ...newPost, title: e.target.value })}
      />
      <textarea
        placeholder="Body"
        value={newPost.body}
        onChange={(e) => setNewPost({ ...newPost, body: e.target.value })}
      ></textarea>
      <button onClick={handlePost}>Create Post</button> 
      // 버튼 클릭 이벤트를 통해 데이터를 POST 요청으로 서버로 전송
    </div>
  );
}

export default App;

🟡 fetch

- fetch: 브라우저 내장 함수
네트워크 요청 시 사용.

import { useState, useEffect } from 'react';

function Posts() {
  const [posts, setPosts] = useState([]); //posts: API로 받은 데이터 저장
  const [loading, setLoading] = useState(true); //loading: 데이터 로딩 상태 알림
  const [error, setError] = useState(null); //error: 에러 발생 시, 해당 메시지 저장

  useEffect(() => {
    fetch('https://jsonplaceholder.typicode.com/posts')
      .then(response => {
        if (!response.ok) {
          throw new Error('Network response was not ok');
        }
        return response.json();
      })
      .then(data => {
        setPosts(data); //loading이 true면 로딩 메시지 표시
        setLoading(false);
      })
      .catch(error => {
        setError(error.message); //loading이 false면 에러 메시지 표시
        setLoading(false);
      });
  }, []); // 빈 배열을 사용하여 처음 마운트될 때만 실행

  if (loading) return <p>Loading...</p>;
  if (error) return <p>Error: {error}</p>;

  return (
    <div>
      <h1>Posts</h1>
      <ul>
        {posts.map(post => (
          <li key={post.id}>{post.title}</li>
        ))}
      </ul>
    </div>
  );
}

export default Posts;

↓ ↓ ↓ ↓

✅ 비동기 처리

API 호출을 async와 await을 이용해 비동기적으로 처리한다면 가독성이 향상되어,
코드들이 어떤 역할을 하는 코드인지, 코드의 실행순서를 직관적으로 확인 가능 + 에러 처리도 용이.

useEffect(() => {
  const fetchPosts = async () => {
    try {
      const response = await fetch('https://jsonplaceholder.typicode.com/posts');
      if (!response.ok) {
        throw new Error('Network response was not ok');
      }
      const data = await response.json();
      setPosts(data);
      setLoading(false);
    } catch (error) {
      setError(error.message);
      setLoading(false);
    }
  };

  fetchPosts();
}, []);

🔵 http

const https = require('https');

https.get('https://jsonplaceholder.typicode.com/posts', (res) => {
  let data = '';
  
  res.on('data', (chunk) => {
    data += chunk;
  });
  
  res.on('end', () => {
    console.log(JSON.parse(data));
  });
  
}).on('error', (err) => {
  console.error(err.message);
});

🟣 dio

import 'package:dio/dio.dart';

void main() async {
  final dio = Dio();

  // GET 요청
  try {
    Response response = await dio.get('https://jsonplaceholder.typicode.com/posts');
    print(response.data);
  } catch (e) {
    print('Error fetching data: $e');
  }

  // POST 요청
  try {
    Response response = await dio.post(
      'https://jsonplaceholder.typicode.com/posts',
      data: {
        'title': 'test',
        'body': 'blahblah',
        'userId': 1,
      },
    );
    print('${response.data}');
  } catch (e) {
    print('Error posting data: $e');
  }
}

📂 유용한 사이트

npm
https://www.npmjs.com/search?q=express

headers를 사용해 설정할 수 없는 헤더 목록.
https://fetch.spec.whatwg.org/#forbidden-header-name

📚 참고 자료

https://dev-coco.tistory.com/98
https://aws.amazon.com/ko/what-is/api/
https://brunch.co.kr/@operator/65
https://gitbook-js.hyobb.com/section4/4-4
https://ko.javascript.info/fetch

'공부 > GDG' 카테고리의 다른 글

React 프로젝트 생성 (0)	2024.10.30
Javascript 2 DOM (5)	2024.10.07
GDG-WEB 2주차 과제 (0)	2024.10.01
Javascript 1-4 연산자 (0)	2024.09.30
Javascript 1-3 제어문 (0)	2024.09.30

'공부/GDG' Related Articles

wa_ter_ve

[FE] 웹&앱 연합 스터디 본문

[FE] 웹&앱 연합 스터디

📌 세션 & 쿠키 (Session & Cookies)

🔍 세션(Session)

⬇️⬇️⬇️

🍪 쿠키(Cookies)

📌 동작 과정

🚧 HTTPOnly 쿠키 - (Web)

📌 HTTP

▷ HTTP 요청 (Request)

▷ HTTP 응답(Response)

📮 HTTP 상태 코드

❤️ 1XX - 정보 응답

💛 2XX - 성공 응답

💚 3XX - redirection

🩵 4XX - 클라이언트 요청 오류

💜 5XX - 서버 오류

⚙️ API 통신

💭 API?

🎈 '클라이언트 - 서버' 통신

◎ API 작동 방식 4가지 유형

◎ API 보호

◎ Open API

💭 CRUD?

📌 HTTP 응답 메소드 (HTTP request method)

GET 요청 ex.

POST 요청 ex.

📌 API 통신 예제

▷ axios 설치 (React)

▷ JSON 서버 설치 (React)

🟠 axios

🟡 fetch

✅ 비동기 처리

🔵 http

🟣 dio

📂 유용한 사이트

📚 참고 자료

'공부 > GDG' 카테고리의 다른 글

티스토리툴바