[react] 회원가입 폼 데이터 기능구현#1 - REST API 개념 익히기

프롤로그

그리디브 개발 스터디에서 진행하고 있는 프로그레시브 앱 MVP 구현하기!
드디어 약 5주차에 걸쳐 회원가입 입력 폼 구현과 디자인 입히기를 마무리 했다.🥳🥳 그리고 이제 데이터를 주고 받을 수 있도록 api 를 붙여보기로 했다. api 를 붙이기 전 REST API 에 대해서 먼저 이론을 익히고 기능을 구현해 보고자 한다.

 

---

REST API 에 대한 이해

 

Representational State Transfer API

REST 를 기반으로 만들어진 API 이다.
그렇다면 REST는 무엇일까?
REST와 API 각각의 개념을 알고 REST API를 이해해 보자 🙂

 

 

REST

자원을 이름으로 구분하여 해당 자원의 상태를 주고 받는 모든 것을 의미한다.

 

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

HTTP Method(POST, GET, PUT, DELETE)를 통해

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

 

 

💡 CRUD Operation ?

CRUD 는 대부분의 컴퓨터 소프트웨어가 가지는 기본적인 데이터 처리 기능인 Create(생성), Read(읽기), Update(갱신), Delete(삭제) 를 묶어서 일컫는 말로 REST 에서의 CRUD 동작 예시는 다음과 같다.

 

Create 데이터 생성 -> POST
Read 데이터 조회 -> GET
Update 데이터 수정 -> PUT
Delete 데이터 삭제 -> DELETE

 

REST 의 구성 요소

 

REST는 3가지로 구성되어 있다.

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

 

 

💡 자원에 대한 행위의 내용? : HTTP에서의 Representation 에 대하여
representation 을 조금 더 자세하게 정의하자면 어떤 리소스의 특정 시점의 상태를 반영하고 있는 정보이다. 하나의 representation은 representation data와 representation metadata로 구성된다.

조금 더 깊은 이해가 필요하다면 이 분의 블로그를 자세하게 읽어보자
representation에 대한 개념을 심도있게 "잘" 설명해주셨다.
REST의 representation이란 무엇인가

 

---

 

REST 디자인 원칙

 

균일한 인터페이스

클라이언트-서버 디커플링

Stateless

캐싱 가능성

계층 구조 아키텍처

코드 온디맨드(옵션)

 

 

 

① 균일한 인터페이스

• Identification of resources : 인터페이스는 클라이언트와 서버 간의 상호 작용에 관련된 각 리소스를 고유하게 식별해야 한다.
• Manipulation of resources through representations : 리소스는 서버 응답에 동일한 표현을 사용해야 합니다. API 소비자는 이러한 표현을 사용하여 서버의 리소스 상태를 수정해야 한다.
• Self-descriptive messages : 각 리소스 표현에는 메시지 처리 방법을 설명하는 충분한 정보가 있어야 한다. 또한 클라이언트가 리소스에 대해 수행할 수 있는 추가 작업에 대한 정보도 제공해야 한다.
  -Hypermedia as the engine of application state : 클라이언트는 애플리케이션의 초기 URI만 가지고 있어야 한다. 클라이언트 애플리케이션은 하이퍼링크를 사용하여 다른 모든 리소스와 상호 작용을 동적으로 구동해야 한다.

 

② 클라이언트-서버 디커플링

클라이언트와 서버 애플리케이션은 서로 간에 완전히 독립적이어야 한다.
클라이언트 애플리케이션이 알아야 하는 유일한 정보는 요청된 리소스의 URI이며, 이는 다른 방법으로 서버 애플리케이션과 상호작용할 수 없다. 이와 유사하게, 서버 애플리케이션은 HTTP를 통해 요청된 데이터에 전달하는 것 말고는 클라이언트 애플리케이션을 수정하지 않아야 한다.

 

③ Stateless

이는 각 요청에서 이의 처리에 필요한 모든 정보를 포함해야 함을 의미한다. 즉, REST API는 서버측 세션을 필요로 하지 않고, 서버 애플리케이션은 클라이언트 요청과 관련된 데이터를 저장할 수 없다.

 

④ 캐싱 가능성

가급적이면, 리소스를 클라이언트 또는 서버측에서 캐싱할 수 있어야 한다. 또한 서버 응답에는 전달된 리소스에 대해 캐싱이 허용되는지 여부에 대한 정보도 포함되어야 한다. (이의 목적은 서버측의 확장성 증가와 함께 클라이언트측의 성능 향상을 동시에 얻는 것이다.)

 

⑤ 계층 구조 아키텍처

REST API에서는 호출과 응답이 서로 다른 계층을 통과한다.

 

⑥ 코드 온디맨드(옵션)

REST API는 일반적으로 정적 리소스를 전송하지만, 특정한 경우에는 응답에 실행 코드(예: Java 애플릿)를 포함할 수도 있다. 이러한 경우, 코드는 요청 시에만 실행되어야 한다.

 

---

 

API

 

Application Programming Interface(애플리케이션 프로그램 인터페이스)
API의 맥락에서 애플리케이션이라는 단어는 고유한 기능을 가진 모든 소프트웨어를 나타낸다. 인터페이스는 두 애플리케이션 간의 서비스 계약이라고 할 수 있다. 이 계약은 요청과 응답을 사용하여 두 애플리케이션이 서로 통신하는 방법을 정의한다.

즉, API는 정의 및 프로토콜 집합을 사용하여 두 소프트웨어 구성 요소가 서로 통신할 수 있게 하는 메커니즘
🙂 더 쉬운말로, 디바이스가 서로 간에 연결하여 통신할 수 있는 방법을 정의하는 규칙 세트라고 할 수 있다.

 

---

 

REST API 란?

REST(REpresentational State Transfer) 아키텍처 스타일의 디자인 원칙을 준수하는 API

위의 REST의 디자인 설계 원칙을 따르는 API 를 말한다. REST에는 여섯 가지의 기본 원칙이 있고, 이 가이드를 준수한 인터페이스는 RESTful하다고 표현한다.
(REST를 만든 로이 필딩은 REST 아키텍쳐 스타일을 따르지 않는 API는 REST API라고 부르지 말아주길 바라고 있다고 한다.)

 

---

 

에필로그

 

API라는 단어는 정말 많이 들어봤는데 정확한 개념을 몰랐었다. REST API에 대한 이론을 찾아보면서 API 란 이런거군, REST 에 대한 개념도 확실히 잡을 수 있었다. REST의 원칙을 정확하게 따르지 않은 API 는 HTTP API 라고 구분해 부르는 것도 알게 되었다. (REST API라는 명칭이 통용적으로 쓰이며 굳어진 듯하나, REST의 아키텍쳐를 정확하게 따른것들과 그렇지 않은 것은 구분하는 것이 좋을 것 같다.) 아마 더 깊은 이론들이 존재하겠지만 우선은 여기정도까지만 알아도 이해하고 구현하는데는 무리 없을 것 같다. 그렇다면 이제 axios 를 활용해서 api 를 회원가입 폼에 붙여보러 가보자!

 

---

 

참고

REST API란
REST의 representation이란 무엇인가
REST 디자인 원칙
What is REST