Http와 Rest API에 대한 간단한 정리

1. HTTP

- HyperText Transfer Protocol

- 링크 기반의 데이터 교환 방식을 의미

- 클라이언트와 서버간의 데이터 교환하는 방식이다

 

1.2 HTTP 동작 방식

- 클라이언트 : 서버에 Request

- 서버 : 클라이언트로부터 받은 요청을 처리한 후 Response를 돌려준다

 

1.3 HTTP 특징

1. 비연결성 (Connectionless)

= 클라이언트와 서버가 연결을 한번 맺었다면 응답을 받으면 연결을 끊음

 

장점 : 클라이언트와 계속 연결을 유지하는 리소스를 줄일 수 있다.

단점 : 연결 및 해제에 대한 오버헤드가 발생, 이에 대한 선택적인 해결책으로 KeepAlive 속성이 존재

 

* KeepAlive : 이 속성을 On이라면 지정된 시간동안 클라이언트에게 주기적으로 패킷을 보내 패킷에 대한 반응을 확인하여 연결을 유지하는 속성, 지정된 시간안에 반응이 없다면 연결을 해제

 

2. 무상태 (Stateless)

= 비연결성 특성에 따라 서버는 클라이언트의 상태(State)를 내부적으로 유지하지 않으면 알지 못한다. 즉, 클라이언트의 이전 상태를 알 수 없는 Stateless한 특성을 가진다.

상태를 유지할 필요가 있다면 쿠키, 세션, 토큰 등을 이용할 수 있다.  

 

장점 : 불특정 다수의 클라이언트가 서버에 요청을 하더라도 최소한의 상태를 유지하여 많은 요청을 처리하는데 용이함

단점 : 상태를 유지하는데 추가적인 방법이 필요하다

 

* State 유지 방법 

- Cookie(쿠키) : 클라이언트 정보를 식별하기 위해 브라우저 단(사용자쪽)에 저장하는 방식의 정보

- Session(세션) : 쿠키와 비슷하지만 서버 단에 저장하는 방식의 정보

- Token(토큰) : 위의 쿠키와 세션의 보안문제를 보완하기 위해 원본 데이터 대신 토큰이라는 치환된 데이터를 사용하는 방식, OAuth, JWT등이 있다

 

1.4 HTTP Status Code

- 서버는 클라이언트에 응답할때 헤더에 응답코드를 추가하여 응답한다.

- 응답에 상태에 대한 정보를 담고 있다.

- developer.mozilla.org/ko/docs/Web/HTTP/Status

HTTP 상태 코드 - HTTP | MDN

1.5 HTTP Method

클라이언트가 서버로 요청을 보낼 때, 어떠한 목적을 가진 요청인지 명시할 수 있는 방법

아래의 각 Method 설명은 이해하기 쉽게 표현한 것이지 정답에 가깝지는 않습니다.

• GET
  • 데이터를 조회하는 목적의 요청
• POST
  • 서버에 데이터를 전송하여 서버의 상태 혹은 데이터의 변화를 목적으로 하는 요청
• PUT
  • 목적 데이터의 전체 수정을 목적으로 하는 요청
  • 하지만 전체가 아닌 대부분의 수정을 목적으로 하는 요청은 대부분 PUT을 사용
• DELETE
  • 데이터의 삭제를 목적으로 하는 요청
• HEAD
  • GET과 같은 응답을 요청하지만 본문(body)를 제외한 헤더만을 반환하도록 요청 
• TRACE
  • 목적 서버까지의 모든 HTTP 애플리케이션의 요청/응답을 따라가면서 요청의 이상 유무를 파악하는데 사용
  • 서버는 요청받은 메시지를 본문으로 하여 응답한다. 즉 보낸 메세지가 돌아오는게 하여 Test를 진행 = loop-back 테스트
• OPTIONS
  • 서버에게 특정 데이터가 어떤 메소드를 지원하는지 요청
• PATCH
  • 목적 데이터의 일부분만 수정할 목적으로 하는 요청

 

2. Restful API

2.1 REST

- Representational State Transfer

- 웹의 장점을 최대한 활용하기 위한 아키텍처

- 웹에 존재하는 모든 자원(이미지, 동영상, DB 자원)에 고유한 URI를 부여해 활용

 

2.2 REST의 특징

아래의 특징들을 만족하면 Restful 하다고 할 수 있다

• Client-Server (클라이언트 / 서버 구조)
• Stateless (무상태)
  • HTTP를 사용하는 사용하는 방식의 아키텍처이므로 HTTP의 특성을 가진다
  • 클라이언트의 상태를 서버에 저장하지 않는다
• Cacheable (캐시 처리 가능)
  • 캐시 처리가 가능한 상태여야 한다
• Hierarchical structure (계층형 구조)
  • REST한 서버는 계층적으로 구성 될 수 있으며 여러 계층을 통해 구조상의 유연성을 줄 수 있다
• Uniform Interface (인터페이스 일관성)
  
  • HTTP 표준에만 따른다면 어떠한 플랫폼에 상관없이 사용이 가능하다
• Self-descriptiveness (자체 표현 구조)
  • API의 URI만 보고도 어떤 메서드가 어떠한 행위를 하는지 알 수 있어야한다

 

2.3 Restful API란

- Restful API는 위의 REST한 특징들을 만족시키는 API를 의미한다

- REST는 설계 가이드이지 표준이 아니기에 설계 규칙 또한 권장이지 필수가 아니다

- REST한 특징들을 최대한 지키되 개발하는 그룹내에서 정의하여 사용하면 된다

 

2.4 Restful API의 URI 설계 권장 규칙

• 소문자 사용
• 하이픈(-, hypen) 사용
• 공백 제거
• CRUD의 행동들의 명시는 URI가 아닌 HTTP 메서드를 이용

 

3. 머리속에 넣기 위한 총정리

HTTP는 클라이언트와 서버간의 링크를 기반으로 데이터를 교환하는 프로토콜이고 비연결성, 무상태의 특징을 가지고 있다. 비연결성과 무상태의 특징을 통해 다수의 요청을 처리하는데 효율적으로 사용할 수 있다.

이러한 HTTP 프로토콜의 장점을 살리기 위해 만들어진 네트워크 기반 아키텍처 REST가 있다. REST는 웹에 존재하는 모든 자원에 고유한 URI를 부여해 활용하겠다는 것으로 클라이언트/서버, 무상태, 캐시 처리 기능, 계층형 구조, 인터페이스 일관성, 자체 표현 구조등의 특징을 가진다. Restful API는 REST한 특성을 가진 API를 의미한다.

 

 

 

---

 

# 참조

- http://www.incodom.kr/REST#h_c9da54c50b7d469b56863a778d4c9695

 

- medium.com/@hckcksrl/rest%EB%9E%80-c602c3324196
- ijbgo.tistory.com/20

 

---

웹개발 초보가 정리한 글입니다

내용에 대한 오류가 있다면 코멘트 언제나 환영합니다!