HTTP, REST API 이해하기

HTTP란?

서버와 클라이언트가 인터넷 상에서 데이터를 주고 받기 위한 프로토콜(일종의 약속)

HTTP 주요 Request 메소드

Request 메소드란? 클라이언트가 서버에 무언가를 요청하는 명령어

GET: 리소스 조회

POST: 주로 등록에 사용, 요청 데이터 처리

PUT: 리소스를 덮어쓰기, 없을 경우 생성

PATCH: 리소스 부분변경

DELETE: 리소스 삭제

HTTP 주요 Response 메시지

Response란? 서버가 클라이언트에 보내는 메시지

Status Line: 200 OK, 404 Not Found와 같은 상태 메시지

Header: 응답과 관련된 다양한 정보를 포함.

Body: 서버가 클라이언트에 반환하는 데이터. HTML 데이터, JSON 데이터 등..

REST

HTTP를 기반으로 한, 웹서비스를 설계하고 통신하기 위한 아키텍처 스타일 및 규칙의 모음.

다음의 3가지로 구성되어 있다.

1. Resource - URI
   • 모든 리소스은 고유한 ID를 가지고, ID는 서버에 존재하며, 클라이언트는 각 리소스의 상태를 조작하기 위해 요청을 보낸다.
   • 이러한 리소스를 구분하는 ID가 ‘user/:user_id’, ‘user/1’ 과 같은 HTTP URI이다.
2. 행위(Verb) - Method
   • 클라이언트는 URI를 이용해 리소스를 지정하고 조작하기 위해 Method를 사용한다.
   • HTTP 프로토콜은 위에서 말한 GET, POST… 등의 메서드를 제공한다.
3. 표현(Representation of Resources)
   • 클라이언트가 서버로 요청을 보냈을 때, 서버가 응답으로 보내주는 리소스의 상태를 의미한다.
   • JSON, XML, TEXT 등 여러 형태로 나타낼 수 있으나, 주로 JSON을 이용한다.

REST의 특징

1. 클라이언트-서버 구조
2. Stateless
3. 캐시 처리 기능
4. 계층 구조
5. 인터페이스 일관성
6. 자체 표현 구조

REST API란?

REST의 특징을 기반으로 서비스 API를 구현한 것. 각 요청이 어떤 동작이나 정보를 위한 것인지 요청 그 자체로 추론 가능하다.

REST API 디자인 가이드

1. URI는 정보의 리소스를 표현해야 한다.
2. 리소스에 대한 행위는 HTTP Method(Get, Post…)로 표현한다.

URI의 설계 규칙

1. URI는 소문자로만 구성한다.
2. URI에는 행위를 포함하지 않는다. ex) GET /getUser/:id X GET /user/:id O
3. 언더바_ 대신 하이픈- 을 사용한다.
4. 슬래시/는 계층 관계를 표현한다.
5. URI의 마지막 문자로 슬래시를 포함하지 않는다.
6. 파일 확장자는 URI에 포함시키지 않는다.
7. URI에서 영어는 복수형으로 작성한다.

REST API vs RESTful API

RESTful API는 REST의 설계 규칙을 잘 지켜서 설계된 API이다. RESTful API는 요청을 보내는 주소만으로도 어떤 것을 요청하는지 파악할 수 있다.

아래 예제를 통해, REST API를 만드는 과정을 확인할 수 있다.

 

참고자료

 

https://velog.io/@yewo2nn16/Spring-%EC%98%88%EC%A0%9C%EC%99%80-%ED%95%A8%EA%BB%98-REST-API-%EC%95%8C%EC%95%84%EB%B3%B4%EC%9E%90

Spring 예제와 함께 REST API 알아보자

https://www.freecodecamp.org/korean/news/rest-api-mobeom-sarye-rest-endeupointeu-seolgye-yesi/

REST API 모범 사례 – REST 엔드포인트 설계 예시