[TIL_3] KB 부트캠프: REST API

 

[TIL_4] KB 부트캠프: REST API

 

 

안녕하세요,
 
'Today I Learned' 4주차에서는
REST API에 대해
작성해보고자 합니다.

좀 더 세부적인 내용은 가장 하단의
타임라인을 참고해주세요.

 

---

목차

1. REST란 무엇인가?

• REST(Representational State Transfer)의 정의
• REST의 주요 개념
• REST의 구성요소
• REST의 특징

2. REST API

• REST API란?
• REST API 디자인 가이드
• REST URI 설계 규칙
• HTTP 상태 코드의 사용

3. RESTful

• RESTful의 정의
• RESTful의 목적
• RESTful하지 못한 예시
  

 

현재 KB IT's Your Life에서 다루는 내용을 기반으로 작성하였습니다.
#KB부트캠프 #KB코딩 #KB코딩테스트
 

---

1.  REST란 무엇인가?

 

REST의 정의

• REST는 Representational State Transfer의 약자로, 자원의 표현을 통해 상태를 주고받는 모든 것을 의미합니다. 이는 월드 와이드 웹(WWW)과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식입니다.
• 쉽게 말해, REST는 네트워크 상에서 클라이언트와 서버 사이의 통신 방식 중 하나로, 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일입니다.
• 예를 들어, 데이터베이스에 저장된 학생 정보가 자원(Resource)일 때, 이를 students라는 URI로 표현하고, 클라이언트가 이 URI를 요청하면 해당 시점의 학생 정보(자원의 상태)를 전달받는 방식입니다.

World Wide Web 출처: 위키피디아

REST의 구성요소

REST는 아래 세 가지 주요 구성요소로 이루어집니다.

1. 자원(Resource) - HTTP URI
   • 모든 자원은 고유한 ID인 HTTP URI를 가집니다.
   • 클라이언트는 이 URI를 통해 자원을 식별하고, 서버에 해당 자원의 상태 조작을 요청합니다.
   • URI와 URL의 차이점을 이해하는 것도 중요합니다.
2. 행위(Verb) - HTTP Method
   • HTTP 메서드인 GET, POST, PUT, DELETE, PATCH 등을 사용하여 자원에 대한 CRUD(Operation)를 수행합니다.
   • 각 메서드는 특정한 행위를 나타내며, 이를 통해 자원을 조작합니다.
3. 표현(Representation) - HTTP Message Body
   • 서버는 클라이언트의 요청에 대한 응답으로 자원의 상태를 JSON, XML, TEXT 등의 형태로 전달합니다.
   • 일반적으로 JSON이나 XML 형식을 많이 사용합니다.

 

REST 출처: OPC ROUTER

 

REST의 특징

REST 아키텍처는 다음과 같은 특징을 가지고 있습니다.

1. Uniform Interface(인터페이스의 일관성)
   • URI로 지정한 자원에 대한 조작을 일관되고 한정적인 인터페이스로 수행합니다.
   • 특정 언어나 플랫폼에 종속되지 않고, HTTP 표준 프로토콜을 따르는 모든 플랫폼에서 사용 가능합니다.
2. Stateless(무상태성)
   • 서버는 클라이언트의 각 요청을 완전히 별개의 것으로 인식하며, 세션이나 쿠키 정보를 저장하지 않습니다.
   • 이러한 무상태성은 서버의 부담을 줄이고, 서비스의 확장성과 유연성을 높입니다.
3. Cacheable(캐시 가능)
   • HTTP의 캐시 기능을 활용하여 응답 결과를 캐싱할 수 있습니다.
   • 이를 통해 대량의 요청을 효율적으로 처리할 수 있으며, 네트워크 트래픽을 감소시킵니다.
4. Layered System(계층화)
   • REST 서버는 여러 계층으로 구성될 수 있으며, 각 계층은 독립적으로 동작합니다.
   • 보안, 로드 밸런싱, 암호화 등의 추가 기능을 계층적으로 구성하여 시스템의 유연성을 높일 수 있습니다.
5. Client-Server 구조
   • 클라이언트와 서버가 역할을 분리하여 개발됩니다.
   • 클라이언트는 사용자 인터페이스와 사용자 경험을 담당하고, 서버는 데이터 저장 및 비즈니스 로직을 처리합니다.

REST API 특징 출처: 티스토리

---

2. REST API

 

REST API의 정의

• REST API는 REST 아키텍처 스타일을 기반으로 서비스 API를 구현한 것을 의미합니다. 이는 웹 서비스 간 상호 작용을 촉진하고, 서로 정보를 교환할 수 있도록 하는 인터페이스입니다.
• REST API의 가장 큰 특징은 각 요청의 형태만으로도 그 요청이 어떤 동작이나 정보를 위한 것인지 추론이 가능하다는 점입니다.

REST API 출처: codcacademy

 

REST API 디자인 가이드

RESTful한 API를 설계하기 위해서는 다음과 같은 가이드라인을 따르는 것이 좋습니다.

1. URI는 자원을 표현해야 한다.
   • URI는 동사보다는 명사를 사용하며, 대문자보다는 소문자를 사용합니다.
   • 예: /students, /orders
2. 자원에 대한 행위는 HTTP Method로 표현한다.
   • HTTP 메서드를 활용하여 자원에 대한 CRUD Operation을 수행합니다.
   • 예:
     • GET /students/1 : 학생 정보 조회
     • POST /students : 새로운 학생 정보 생성
     • PUT /students/1 : 학생 정보 전체 수정
     • PATCH /students/1 : 학생 정보 일부 수정
     • DELETE /students/1 : 학생 정보 삭제
3. URI에는 행위를 나타내는 동사가 들어가면 안 된다.
   • 잘못된 예: /getStudent, /createStudent
   • 올바른 예: /students
4. 경로 중 변하는 부분은 유일한 값으로 대체한다.
   • 예: /students/{student_id}, /orders/{order_id}

RESTFUL 규칙 출처: flab

 

REST URI 설계 규칙

 

RESTful한 URI를 설계하기 위해서는 다음과 같은 규칙을 따릅니다.

1. 슬래시(/)는 계층 관계를 나타낸다.
   • 예: /users/{user_id}/orders/{order_id}
2. URI의 마지막에는 슬래시(/)를 포함하지 않는다.
   • 올바른 예: /products
   • 잘못된 예: /products/
3. 하이픈(-)을 사용하고 언더바(_)는 사용하지 않는다.
   • 예: /user-orders (O), /user_orders (X)
4. 파일 확장자는 URI에 포함하지 않는다.
   • 데이터 포맷은 Accept 헤더를 통해 지정합니다.
   • 잘못된 예: /users.json
   • 올바른 예: /users + Accept: application/json
5. URI는 소문자로 작성한다.
   • 일부 시스템에서는 대소문자를 구분하므로, 소문자를 사용하는 것이 좋습니다.
   • 예: /users, /orders
6. HTTP 상태 코드를 적절히 사용한다.
   • 예:
     • 200 OK : 성공적인 요청
     • 201 Created : 새로운 리소스 생성
     • 400 Bad Request : 잘못된 요청
     • 404 Not Found : 리소스를 찾을 수 없음
     • 500 Internal Server Error : 서버 내부 오류

REST API 규칙 출처: 티스토

---

3. RESTful

RESTful의 의미

• RESTful은 REST 아키텍처의 원칙을 올바르게 준수하여 설계된 시스템을 의미합니다.
• 단순히 REST를 사용했다고 해서 RESTful한 것은 아니며, REST의 설계 원칙과 스타일을 철저히 따르는 시스템만이 RESTful하다고 할 수 있습니다.

 

RESTful의 목적

• RESTful의 주된 목적은 이해하기 쉽고 사용하기 쉬운 API를 만드는 것입니다.
• 이는 일관된 컨벤션을 통해 API의 이해도와 호환성을 높이는 것을 목표로 합니다. 따라서 성능이 가장 중요한 상황이 아니라면, RESTful한 API 설계는 매우 유용합니다.

 

RESTful하지 않은 사례

다음은 RESTful하지 않은 API 설계의 예시입니다.

• 모든 CRUD 기능을 POST 메서드로만 처리하는 경우
  • 이렇게 하면 HTTP 메서드의 의미가 사라지고, API의 의도가 명확하지 않게 됩니다.
• URI에 행위를 나타내는 동사가 포함된 경우
  • 예: /getAllUsers, /deleteOrder/123
  • 이러한 URI는 REST의 자원 중심 설계 원칙에 어긋납니다.

 

4. 컴포넌트 백엔드 교육3 타임라인 정리

 
👩‍💻타임라인
 
1일차: Spring 서버로 화면 처리

2024.08.12 - [KB IT's Your Life/교육] - [066] Spring: 서버로 화면 처리

 

2일차: Spring 화면 처리 - BoardController

2024.08.13 - [KB IT's Your Life/교육] - [067] Spring 화면 처리 - BoardController

 

3일차: REST API

2024.08.14 - [KB IT's Your Life/교육] - [068] REST API

 

---

 

👀 REST API를 왜 공부할까

REST API는 현대 웹 개발의 기본 중의 기본이자, 모든 웹 서비스의 핵심 요소라는 걸 알게되었다.

웹 개발의 기본기를 채우기 위해!

REST API는 웹 서비스의 설계와 구현에 있어 가장 기본적인 개념이라고 한다.

클라이언트-서버 간의 통신 방식을 명확히 이해할 수 있고, 어떻게 데이터를 주고받고 처리하는지에 대한 큰 그림을 그리는 데 필수적이다.

현업에서의 실무 능력을 키우기 위해!

실제 많은 기업에서 REST API를 기반으로 한 서비스를 운영하고 있다.

RESTful한 API를 설계하고 구현하는 능력은 현업에서 꼭 필요한 스킬이다!

 

이를 잘 이해하고 다룰 줄 안다면, 개발자로서의 역량을 한 단계 업그레이드할 수 있지 않을까?

또한, REST API를 잘 이해하면 다양한 오픈 API를 활용한 프로젝트도 스스로 진행할 수 있을 것 같다.

다른 개발자와의 협업을 위해!

개발은 결코 혼자 하는 일이 아니다.

그리고 REST API는 백엔드와 프론트엔드를 연결하는 다리 역할을 한다.

 

REST API를 이해하고 있다면, 팀원들과의 협업이 훨씬 수월해진다.

서로 명확하게 의사소통할 수 있고, API 문서를 작성하거나 해석할 때 혼란 없이 진행할 수 있는데 필수적이다.

더 나은 코드를 작성하기 위해!

REST API의 설계 원칙을 잘 따르는 것은 곧 좋은 코드를 작성하는 것과도 같다.

RESTful한 접근 방식을 익혀두면, 탄탄한 개발 습관을 기를 수 있지 않을까 ..

 

결론적으로 REST API를 공부하는 것은 단순히 하나의 기술을 배우는 것을 넘어, 개발자로서의 기초 체력을 다지고, 미래의 가능성을 넓히는 길이라고 생각한다. 

 

---

 

📒TIL을 마무리하며..

 

4주차 TIL을 작성하면서 REST에 대해 자세히 알아보았습니다.

 

현재 배우고 있는 REST가 추후 실무에서도 많이 사용될 것이라는 생각이 들었고,

이를 기반으로 CS 면접 질문을 만들어 복습하려고 합니다.

 

또한, CS 면접에서 자주 나오는 질문들도 정리해볼 계획입니다.

혹시 궁금한 점이나 조언이 있으시면 언제든지 문의해 주세요. 감사합니다!

 

 

kb 부트캠프 합격 후기 기자단