[Network] : REST API vs. Web Socket

Donghee Kim·2025년 9월 21일

문득문득

목록 보기

2/15

Web Socket을 관리한다고 많이 들었는데 Web Socket이 정확히 뭐고..? Rest API 이런 것들과 어떤차이인지…잘 모르겠어서 미리미리 찾아보기

REST란?

REpresentational State Transfer?
자원을 이름으로 구분하여 해당 자원의 상태를 주고 받는 모든 것을 의미함.

HTTP URI 를 통해 자원(Resource)를 명시하고

HTTP Method(POST, GET, PUT, DELETE, PATCH 등)을 통해

해당 자원(URI)에 대한 CRUD Operation을 적용하는 것을 의미 함.

REST 의 구성 요소

자원(Resource) : HTTP URI
자원에 대한 행위(Verb) : HTTP Method
자원에 대한 행위의 내용(Representations) : HTTP Message Pay Load

REST의 특징

Server-Client 구조
Stateless (무상태)
⇒ 각 요청을 독립적으로 처리하며, 요청 간의 상태를 저장하지 않음.
즉, 서버는 클라이언트가 “이 요청 전에 무슨일이 있었는지..?” 모름.
모든 정보를 요청안에 포함해서 보내야함.
- 브라우저 단에서 쿠키라는 것을 저장하여 **서버가 클라이언트를 식별 가능하게 함.
- 또는 서버단에서 세션이라는 사용자 정보를 저장할 수도 있음.
- 또는 OAuth/JWT** 과 같은 토큰 기반의 인증 방식도 가능함.
```
⇒ 세 가지 마다 장단점이 있기에 경우에 따라 사용해야 함.
```
Cacheable (캐시 처리 가능)
- 서버 부하 감소: 같은 요청이 여러 번 서버로 가지 않아도 됨
- 응답 속도 향상: 가까운 위치(클라이언트나 프록시 서버 등)에서 데이터를 불러오므로 빠름
- Web Cache 종류 :
  - Browser Cache (Client - side) : 클라이언트가 응답을 저장하고 다음 요청에서 재사용
  - Proxy Cache (CDN, Network-side) : 중간 네트워크 계층에서 캐싱
  - Server Cache (Memory Redis) : 서버 내부에서 캐싱 (memory, Redis)
Layered System (계층화) ⇒ Rest Server는 보안/Load Balancing/암호화 등 다중 계층으로 구성할 수 있고, Proxy & Gateway 등의 중간 매체를 사용할 수 있다.
Uniform Interface (인터페이스 일관성)
⇒ 플랫폼 언어 제약 없음.

REST 장단점

장점

HTTP 프로토콜의 Infra를 그대로 사용하므로 별도의 Infra 구축이 필요 없음
모든 플랫폼에서 사용 가능
서버와 클라이언트의 역할을 명확하게 분리
HTTP 프로토콜의 표준을 최대한 활용

단점

HTTP Method 형태가 제한적이다.
정보가 변하는 경우, 그 때에만 정보를 받아오는 것이 힘들다는 것이다. 정보를 받아오려면 계속 요청을 반복해서 해야한다.

한 번 뜨고 나면 그 결과가 변하지 않는다.

예를 들어 사이트에 들어갔을 때 아무 행위도 하지 않는다면 그대로 있다.

그런데 주식창을 생각해보면 아무것도 하지 않았는데, 계속해서 변동되는 주가가 보인다.

만일 이것을 REST API 로 만든다면 지속적으로 데이터를 요청하며 새로고침 하는 셈이 되는 것이다.

무한 반복으로 초당 10,000번 불러오게 만든다고 해도 어떤 주식의 값은 변하지 않을 수도 있는데 계속 불러오게 되는 자원 낭비가 일어나는 것이다.

REST API

사실 REST API 는 API 중 몇 가지 특성을 가진 특정 API의 종류일 뿐이다.
⇒ 현재 대부분 많이 쓰이는 방식이다.

그렇다면..?

한 번만 요청하고, 그 뒤로 정보가 변할 때마다 그냥 불러오도록 할 수는 없을까?

여기서 새로운 방식의 API 가 필요하게 된다.

Web Socket?

Web Socket?
Web Socket은 웹 앱과 서버 간의 지속적인 연결을 제공하는 프로토콜

⇒ 이를 통해 Server 와 Client 간에 양방향 통신이 가능해진다. HTTP 와는 달리, WebSocket연결은 한 번 열린 후 계속 유지된다.
그렇기에, 실시간으로 진행되는 통신에서 적극적으로 사용하고 있다.

Web Socket 등장 배경

HTTP를 이용한 Request ↔ Response 통신 방식의 모델은 현재 가장 많이 쓰는 기술 중 하나이며 작업에 큰 문제는 없다.

하지만, 실시간으로 데이터를 주고 받는 데에는 한계점이 발생한다.

요청과 응답이 있다는 것은 클라이언트가 서버에게 요청하지 않는 이상 서버는 클라이언트에게 먼저 데이터를 보낼 수 없게 되기 때문에 클라이언트는 항상 새로운 데이터가 있는지 확인을 하기 위해서는 서버에 지속적으로 요청을 보낼 수밖에 없습니다.

⇒ 불필요한 트래픽을 증가 시키고, 서버의 비용이 증가될 뿐더러 요청과 응답 사이의 지연시간이 있기 때문에 실시간 통신의 효율성이 저하된다.

자세히 Web Socket 이란?

Web Socket은 HTML5에 등장 실시간 웹 애플리케이션을 위해 설계된 통신 프로토콜이며, TCP 를 기반으로 한다.
⇒ TCP를 기반으로 한 Web Socket은 신뢰성 있는 데이터 전송을 보장하며, 메시지 경계를 존중하고, 순서가 보장된 양방향 통신을 제공할 수 있다.

데이터는 패킷(packet)형태로 전달되며, 전송은 연결 중단과 추가 HTTP 요청 없이 양방향으로 이뤄진다.

Web Socket 동작 방식

1. Client 가 HTTP를 통해 Web Socket 연결 요청

⇒ “handshake”

서버가 연결 요청을 받아 Web Socket으로 Upgrade

⇒ TCP로 변경됨.
양방향 통신 시작
연결 유지 (연결이 끊이지 않도록 ping/pong message)
연결 종료

Upbit WebSocket API..?

Ref : https://minf.tistory.com/entry/WebSocket-%EC%97%85%EB%B9%84%ED%8A%B8-%EC%9B%B9%EC%86%8C%EC%BC%93webSocket%EA%B3%BC-%ED%86%B5%EC%8B%A0%ED%95%B4%EB%B3%B4%EC%9E%90-feat-blob-%EB%8D%B0%EC%9D%B4%ED%84%B0