[TIL]20240717 RESTful의 의미

웹미니프로젝트를 같이하던 팀장님이 발표를 하면서 가장 많이 한 말이 RESTful 하지않다는 말이였다. 그때 알아본다알아본다 하면서 잊고있다가 주특기 주차에 와서 RESTful의 의미를 알아두면 좋을 것이라는 기술매니저님의 조언에 공부를 할 수 밖에 없었다... 어차피 앞으로 계속 써야하는 단어같은데, 이 참에 공부해두고 개발자처럼 써먹어야겠다. 

REST(Representational State Transfer)는 웹 서비스의 설계 원칙 중 하나로, RESTful은 이러한 REST 원칙을 준수하여 설계된 웹 서비스를 의미한다. 웹 애플리케이션의 설계 시 RESTful은 클라이언트-서버 구조를 더 효율적이고 일관성 있게 만들어 주기 때문에, 이를 이해하는 것은 매우 중요하다. 

 

▶ REST란?

REST(Representational State Transfer) 는 네트워크 상에서 클라이언트와 서버 간의 상호작용을 정의하는 일련의 제약 조건을 제공하고, 이러한 제약 조건을 기반으로 확장성과 성능이 뛰어난 애플리케이션을 설계할 수 있다.

 

REST는 다음과 같은 주요 원칙을 기반으로 한다

→ 클라이언트-서버 구조:

클라이언트와 서버는 서로 독립적이어야 하고, 클라이언트는 요청을 보내고 서버는 해당 요청에 대한 응답을 처리하는 구조를 가진다.

→ 무상태(Stateless):

각 요청은 완전하고 독립적인 요청이어야 하고, 서버는 이전 요청에 대한 정보를 유지하지 않아야 한다. 모든 요청은 필요한 모든 정보를 자체적으로 포함해야 한다.

→ 캐시 가능(Cacheable):

클라이언트는 서버 응답을 캐시해서 동일한 요청에 대한 응답을 재사용할 수 있다. 이를 통해 네트워크 트래픽을 줄이고 성능을 향상시킬 수 있다.

→ 계층적 시스템(Layered System):

클라이언트와 서버 사이에 중간 계층(프록시, 게이트웨이 등)을 둘 수 있으며, 각 계층은 다른 계층에 대한 정보를 알 필요 없이 독립적으로 동작할 수 있다.

→ 인터페이스 일관성(Uniform Interface):

RESTful 시스템의 핵심으로, URI를 통해 자원(Resource)을 식별하고, HTTP 메서드를 통해 자원에 대한 행동을 정의하는 일관된 인터페이스를 제공해야 한다.

→ Code on Demand (선택적):

서버가 클라이언트에게 실행 가능한 코드를 제공할 수 있다. (예: 자바스크립트)

 

▶ RESTful의 의미

RESTful이란, 위의 설명처럼 REST의 원칙을 준수하여 설계된 웹 서비스를 의미한다. RESTful 웹 서비스는 HTTP 프로토콜을 기반으로, 클라이언트가 서버의 자원에 접근하고, 다양한 작업(Create, Read, Update, Delete)을 수행할 수 있도록 한다.

RESTful은 다음과 같은 특징을 가진다

→ Representation of Resource :

URI(Uniform Resource Identifier)를 통해 고유하게 자원을 식별하고, HTTP 메서드를 통해 자원에 대한 작업을 수행한다.

→ 표준 HTTP 메서드 사용:

RESTful API는 HTTP의 표준 메서드를 사용하여 자원에 대한 CRUD(Create, Read, Update, Delete) 작업을 수행한다.

- GET : 조회

- POST : 생성

- PUT : 업데이트

- DELETE : 삭제 

→ 상태 정보의 관리:

RESTful API는 상태 정보를 클라이언트에 유지하며, 서버는 무상태로 동작한다.

 

▶ RESTful API의 예시 

RESTful API를 구현할 때, 가장 중요한 것은 자원을 어떻게 식별하고 HTTP 메서드를 통해 자원에 대한 행동을 정의하는 것이다. 아래는 예시로 보여주는 회원 관리 시스템의 RESTful API 설계이다.

 

회원 관리 API 설계

회원 목록 조회	GET	/users	모든 회원 정보를 조회한다.
회원 정보 조회	GET	/users/{id}	특정 ID를 가진 회원의 정보를 조회한다.
회원 생성	POST	/users	새로운 회원을 생성한다.
회원 정보 수정	PUT	/users/{id}	특정 ID를 가진 회원의 정보를 수정한다.
회원 삭제	DELETE	/users/{id}	특정 ID를 가진 회원을 삭제한다.

→ 회원 관리 시스템을 위한 RESTful API 설계를 보여준다. 각 API 엔드포인트는 다음과 같은 RESTful의 원칙을 따른다

 

→ 회원은 고유한 URI(/users 또는 /users/{id})로 식별된다.

→ HTTP 메서드 사용:

각 작업(Create, Read, Update, Delete)은 HTTP 메서드(GET, POST, PUT, DELETE)로 정의된다.

→ 무상태(Stateless):

각 요청은 독립적으로 처리되고, 서버는 클라이언트의 상태를 유지하지 않는다.

→ 일관된 인터페이스:

모든 요청은 URI와 HTTP 메서드를 사용하여 일관된 방식으로 이루어진다.

 

▶ RESTful의 장점

→ 확장성(Scalability):

클라이언트와 서버가 독립적으로 확장될 수 있어, 애플리케이션의 확장성을 높일 수 있다.

→ 유연성(Flexibility)과 유지보수성(Maintainability):

표준화된 HTTP 프로토콜을 사용하므로, 다른 시스템 간의 통합이 용이하며 유지보수 비용이 줄어든다.

→ 보안(Security):

HTTP 표준을 따르므로, HTTPS를 이용한 보안 기능을 쉽게 적용할 수 있다.

→ 캐시 사용 가능:

클라이언트는 서버의 응답을 캐시하여 성능을 최적화할 수 있다.

 

▶ RESTful을 사용할 때 주의할 점

RESTful의 원칙을 제대로 지키지 않으면 API의 일관성과 성능이 떨어질 수 있다🫨

→ URI는 동사보다는 명사를 사용해야 한다:

/createUser 대신 /users와 같은 방법을 사용하고, 작업은 HTTP 메서드를 통해 정의해야 한다.

→ 자원의 계층 구조를 잘 설계해야 한다:

/users/{userId}/orders와 같이 관계를 명확하게 표현해야 한다.

→ 과도한 서버 상태 유지:

RESTful의 무상태 원칙을 깨지 않도록, 서버는 클라이언트의 상태를 유지하지 않아야 한다.

 

▶ 정리

RESTful은 현대 웹 서비스 설계의 핵심 원칙 중 하나로, 효율적이고 일관된 인터페이스를 제공하기 위해 필수적이다. RESTful의 원칙을 준수하여, 확장 가능하고 유지보수하기 쉬운 웹 애플리케이션을 설계를 해야하는데... 아직은 너무 어렵다. 설계라는 말만 들어도 과제하면서 코드작성보다 가장 많이 고민하고 걱정하는 부분이라 정말 잘 알아둬야한다. 특히 오늘 내용은 어려운 말들이 너무 많이나와서 하나하나 알아보느라 유독 많은 시간이걸렸다. 하지만 꼭 준수해야하는 부분이라고 하니까 열심히 머릿속에 집어넣어야겠다.