"클라이언트와 서버가 혹은 서버와 서버가 웹을 이용해서 통신을 할때 정해진 규칙이 있다면 얼마나 좋을까"

그 규칙 중 하나로 REST API에 대한 내용을 살펴봅니다.

---

우선 REST API란 RESTful한 API를 말하며, 위에서 말한 규칙 등을 지키는 API를 말합니다.

해당 내용에서 "API는 어플리케이션 간에 지정된 형식으로 요청과 응답을 할 수 있도록 연결하는 것" 으로 해석하면 됩니다.

---

우선 간단한게 주요 특징을 살펴보자면

REST API는 인터넷 식별자(URI - Uniform Resource Identifier)와 HTTP를 기반으로 하며,

어떠한 데이터 타입으로 통신할 것인가에 대한 규칙은 없고 정답 또한 없지만 보통 브라우저간의 호환성이 좋은 JSON을 주로 사용합니다.

가장 중요한 포인트

가장 중요한 특징은 각 요청이 어떤 정보나 동작을 위한 것인지 URI와 Method만으로 추론이 가능하다는 점입니다. (해당 내용은 아래서 자세하게 다룹니다.)

문서, 그림, 데이터 등의 자원을 이름으로 구분해서 해당 자원에 대한 상태, 정보를 주고 받는 것을 의미하고, HTTP Method를 활용해서 해당 자원에 대한 CRUD를 적용하는 것을 의미합니다.

많은 메서드가 존재하지만 대표적으로 5가지

• GET - 읽기
• POST - 쓰기
• PUT/PATCH - 수정
• DELETE - 삭제

정리하면 REST API는 HTTP 요청을 할 때 어떤 URI에 어떤 Method를 사용할지에 대한 개발자들이 사용하는 약속입니다.

---

REST API의 특징

RESTful하다는 의미가 무엇인지 REST API의 대표적인 특징은 무엇인지 하나씩 살펴봅니다.

Uniform Interface

위에서 REST API에 대해 가장 중요한 포인트로 각 요청이 어떤 정보나 동작을 위한 것인지 URI와 Method만으로 추론이 가능하다는 점이라는 것은 아래로 설명할 수 있습니다.

1. "자원(리소스)은 URI로 식별되어야 한다."
2. "표현을 통한 자원조작"

위 두가지 내용을 가지고 예를 들어보자면

클라이언트와 서버가 학교에 대한 데이터를 주고 받는다고 가정해봅니다.

// 전체 학급 데이터를 가져온다.
1. URI /classes
2. URI /getClasses

URI에는 자원(리소스)만을 나태내야합니다.

classes는 학급 전체의 데이터라는 것을 유추할 수 있습니다.
getClasses에서 get은 어떠한 동작을 할지 URI를 통해 나타내고 있기 때문에 옳은 방법이 아닙니다.

어떠한 행위를 할 때는 GET, POST 등과 같은 HTTP의 고유한 메소드를 이용해야 합니다.

// 전체 학급 데이터를 가져온다.
1. GET Method URI /classes
2. GET Method URI /getClasses

RESTful 하기 위한 규칙은 위 사항 말고 몇가지 규칙이 더 존재합니다.

URI에 대한 규칙

1. URI는 동사가 아닌 고유한 명사로 이루어져야 한다.
2. URI는 계층적인 구조를 가져야한다 ( /반/학생/몇번학생 )
3. 소문자만 사용하되, 너무 긴 내용은 - 를 사용한다
4. 적절한 쿼리스트링을 혼재해서 사용한다.

고유한 명사를 사용하는 이유는 그래야 DB에서 고유 식별자(unique identifier)로 사용할 수 있기때문

HTTP Method에 대한 규칙 ( 고유한 메소드 사용 )

• GET - 읽기
• POST - 쓰기
• PUT/PATCH - 수정
• DELETE - 삭제

🧐 HTTP 고유한 메소드 사용

POST만 가지고도 읽고, 쓰고, 지우고, 수정하고 다 할 수 있습니다만,

학급반 학생에 대한 데이터 생성/읽기/수정/삭제에 대한 행위를 POST로만 한다고 해보면

❌
POST classes/3/students/create/
POST classes/3/students/read/
POST classes/3/students/3/update/
POST classes/3/students/3/delete/

위처럼 동사를 사용해서 URI에 어떠한 행위인지 불필요하게 알려줄 필요가 있습니다.

❌
POST /createClasses/

혹 다른 개발자는 위와 같은 모습일 수 있습니다. 약속과는 거리가 멀게 작성이 될 수 밖에 없습니다.

⭕
//모든 학급들을 보고싶으면
GET /classes

//햇님반의 모든 학생을 보고 싶으면
GET /classes/sun/students

//햇님반의 3번 학생을 보고 싶으면
GET /classes/sun/students/3

//혹은 반이 너무 많아서 조금씩 보고 싶다면
/classes/sun/students?page=3 // 등과 같이 pagination 기능을 사용할 수 있다.

//학급을 추가하고 싶으면
POST /classes

//햇님반에 학생을 추가하고 싶으면
POST /classes/sun/students

//햇님반에 3번 학생의 정보를 수정하고 싶다면
PUT /classes/sun/students/3
PATCH /classes/sun/students/3

//햇님반에 학생이 하나도 없어서 햇님반을 삭제하고 싶다면
DELETE /classes/sun

따라서 HTTP Method와 URI에 사용하는 명사들을 결합해서 위와 같이 만들어 줄 수 있다.

❗ /classes로 delete와 update는 하면 안된다. | 해도 막힐 것이다.
모든 학급을 삭제하거나 모든 학급을 수정하진 않을 테니까

---

다른 특징을 살펴보자

self-descriptive messages

HTTP Header에 타입을 명시하고 각 메시지(자원)들은 MIME type에 맞춰 표현되어야 한다.

만약 json 타입을 반환한다면? application/json으로 명시해주어야 한다.

• MIME types이란 문서, 파일 등의 특성과 형식을 나타내는 표준으로, font/ttf, text/plain, text/csv 등을 말한다

즉, json 타입의 데이터를 보낼 때는
헤더의 "Content-Type" = "application/json"을 명시해야 한다

---

stateless

http 요청에 대한 내용에 추가로 stateless 라는 규칙도 포함됩니다.
사실 정확히는 REST API에 대한 규칙이 아닌, http에 대한 규칙이다.

http 자체가 stateless 즉, 상태를 유지하지 않기 때문에 http를 사용하면 자동으로 충족되는 조건입니다만.

한가지 예를 들어 로그인에 대한 기능을 구현한다면?

새로고침을 해도 로그인이 유지가 될텐데, 이를 위한 구현 방법은 sesstion, token 등등 여러가지 방법이 있을 텐데

앞서 말했듯 REST API는 상태가 없다는 특징을 가지고 있기 때문에 세션에 대한 로직을 넣지 말아야한다는걸 의미합니다.

즉, REST API를 제공해주는 서버는 세션(session)을 해당 서버 쪽에 유지하지 않는다는 의미입니다. (유저의 상태가 서버에 저장되는 세션기반 방식은 사용하면 안된다)

---

상태코드 status code

결과를 출력할 때는 응답 코드를 정확하게 사용한다.

❌

• 성공은 200
• 실패는 404

상태코드의 종류는 어떤 요청과 응답이냐에 따라 매우 다양합니다.

따라서 상태 코드를 응답하게 될 때에는 어떠한 결과냐에 따라 정확한 상태 코드를 출력하는 것 또한 클라이언트와 서버간의 통신에 있어 매우 중요한 규칙이자 좋은 협업으로 가는 길입니다.

---

이렇게 모아보니 의문점이 생깁니다.🤔

몇가지만 제외하면 이것들은 모두 HTTP에 대한 통신 규칙/규약과 동일한 내용들입니다.

사실 REST API는 특정 기술을 의미하는게 아니라 HTTP가 가진 규칙/규약등의 특징을 사용하는 모범사례입니다.

즉 REST API는 사실 HTTP 프로토콜을 HTTP 프로토콜 답게! 정석으로 사용하자! 라는 의미라고 생각할 수 있습니다.😃