[React] RESTful API란?

🗣️ RESTful API에 대해 설명해주세요.

• 의도: 지원자가 RESTful API의 개념과 이를 사용하는 방법을 이해하고 있는지 평가

• 팁

  • REST의 정의와 원칙을 설명한다.
  • RESTful API의 주요 특징과 HTTP 메서드(GET, POST, PUT, DELETE)의 사용 사례를 언급한다.
  • RESTful API를 사용하는 예제를 떠올려 본다.

• 나의 답안

  RESTful API는 REST, 즉 Representational State Transfer 아키텍처 스타일을 따르는 API를 말합니다.
  REST의 핵심 원칙은 자원을 URI로 표현하고, HTTP 메서드를 사용해 자원을 조작하는 것입니다.

  RESTful API의 특징은 무상태성, 일관된 인터페이스, 클라이언트-서버 분리 등이 있습니다.
  이런 구조 덕분에 프론트엔드에서는 백엔드와 독립적으로 개발이 가능하고, 코드의 재사용성과 유지보수성이 높아집니다.

• 주어진 답안 (모범 답안)

  REST는 Representational State Transfer의 약자로, 자원을 URI로 표현하고 HTTP 메서드를 통해 조작하는 아키텍처 스타일입니다.
  RESTful API는 클라이언트와 서버 간의 통신을 위한 인터페이스로, 일관성과 예측 가능성을 제공합니다.

  GET은 데이터를 조회할 때, POST는 데이터를 생성할 때, PUT은 데이터를 업데이트할 때, DELETE는 데이터를 삭제할 때 사용됩니다.

---

📝 개념 정리

🌟 REST란?

• REST(Representational State Transfer)는 2000년 로이 필딩(Roy Fiedling)이 발표한 논문에서 제안한 웹 아키텍처 스타일이다.
• REST는 클라이언트와 서버 간의 통신을 간결하고 효율적으로 설계할 수 있도록 하는 원칙과 제약 조건을 정의한다.
• RESTful API는 이러한 REST 원칙을 준수하여 설계된 API를 의미한다.

---

🌟 REST의 주요 특징

RESTful API는 아래 6가지 제약 조건을 준수해야 한다.

1. 클라이언트-서버 구조 (Client-Server Architecture)
   • 클라이언트와 서버의 역할을 분리하여 확장성과 유지보수성을 높인다.
   • 클라이언트는 UI/UX를 담당하고, 서버는 데이터 저장 및 로직 처리를 담당한다.
   • 서버가 변경되어도 클라이언트에는 영향을 주지 않도록 독립적으로 설계한다.

2. 무상태성 (Stateless)
   • 서버는 클라이언트의 상태를 저장하지 않는다.
   • 각 요청(Request)은 독립적이며, 필요한 모든 정보를 포함해야 한다.
   • 예를 들어, 세션(session) 대신 토큰 기반 인증(JWT, OAuth)을 사용하여 클라이언트가 인증 정보를 직접 관리하도록 설계할 수 있다.

3. 캐시 가능 (Cacheable)
   • 응답(Response)에 캐싱 가능 여부를 명시하여 성능을 최적화할 수 있다.
   • 예를 들어, HTTP 응답 헤더에 Cache-Control, ETag 등을 설정하여 클라이언트가 캐싱할 수 있도록 한다.

4. 계층화된 시스템 (Layered System)
   • 클라이언트는 API 서버와 직접 통신하지만, 내부적으로는 여러 계층(예: 로드 밸런서, 프록시, 인증 서버 등)이 존재할 수 있다.
   • 이러한 계층화 구조는 보안 강화 및 확장성 증가에 도움을 준다.

5. 인터페이스 일관성 (Uniform Interface)
   • RESTful API는 일관된 URI 및 요청 방식을 유지해야 한다.
   • 주요 원칙
     • 자원(Resource)을 식별하는 고유한 URI
     • HTTP 메서드(GET, POST, PUT, DELETE)의 명확한 사용
     • Self-descriptive 메시지 (명확한 요청과 응답 구조)
     • HATEOAS(Hypermedia As The Engine Of Application State) 적용 가능

       ⭐ HATEOAS란?
       HATEOAS는 RESTful API의 원칙 중 하나로, 클라이언트가 API의 응답을 통해 다음에 수행할 수 있는 액션(링크)을 동적으로 알 수 있도록 하는 개념이다.
       즉, API 응답이 단순한 데이터만이 아니라, 관련된 액션을 포함하는 하이퍼미디어(hypermedia)를 제공해야 한다는 원칙이다.

       ⭐ HATEOAS 개념 정리

       • HATEOAS의 핵심 아이디어
         💖 클라이언트는 API의 엔드포인트(URL)를 사전에 몰라도 된다.
         💖 서버가 응답에 관련된 링크를 포함하여 클라이언트가 자동으로 탐색이 가능하다.
         💖 RESTful API에서 하이퍼링크를 이용하여 리소스 간의 관계를 표현한다.
       • 예제 없이 쉽게 설명하면?
         💖 웹사이트에서 하나의 링크를 클릭하면 다음 동작(페이지 이동, 더 보기 등)이 가능하듯이,
         💖 API 응답에서도 현재 리소스에 대한 정보 + 다음 요청을 위한 링크를 포함하는 방식

       ⭐ HATEOAS 적용 예제

       • HATEOAS 없이 일반적인 REST API 응답

         {
           "id": 1,
           "name": "이순신",
           "email": "lee@example.com"
         }

         문제점
         💖 클라이언트가 "이순신"의 정보를 수정하려면 사전에 엔드포인트(/users/1/edit 등)를 알고 있어야 한다.
         💖 API가 확장될 경우 클라이언트 코드도 변경해야 한다.
       • HATEOAS를 적용한 REST API 응답

         {
           "id": 1,
           "name": "이순신",
           "email": "lee@example.com",
           "_links": {
             "self": { "href": "/users/1" },
             "edit": { "href": "/users/1/edit" },
             "delete": { "href": "/users/1/delete" },
             "orders": { "href": "/users/1/orders" }
           }
         }

         개선된 점
         💖 API 응답에 사용자가 수행할 수 있는 액션을 포함한다.
         💖 클라이언트는 응답만 보고도 다음 동작(수정, 삭제, 주문 보기 등)을 알 수 있다.
         💖 API 구조가 바뀌어도 클라이언트가 하드코딩한 URL을 바꾸지 않아도 된다.

       ⭐ HATEOAS의 장점

       1. 클라이언트의 유연성 증가
          API 구조 변경이 일어나도, 클라이언트는 서버의 응답을 참고하여 동적으로 API를 탐색한다.
       2. 문서화 필요성이 줄어듦
          API 응답 내에 가능한 액션(링크)을 포함하므로, 명시적인 API 문서 없이도 사용이 가능하다.
       3. REST의 자율 탐색성(self-discoverability) 보장
          클라이언트는 사전 지식 없이도 API를 탐색할 수 있다.

       ⭐ HATEOAS의 단점

       1. 응답 크기가 커짐
          링크 정보를 포함하다 보니, 일반적인 JSON 응답보다 데이터가 증가한다.
       2. 구현이 복잡
          서버에서 각 리소스에 대해 적절한 링크를 동적으로 생성해야 한다.
       3. REST API를 호출할 때 오버헤드 발생
          필요한 링크를 찾기 위해 여러 개의 API 호출이 필요할 수 있다.

6. 코드 온 디맨드 (Code on Demand, 선택적)
   • 클라이언트가 필요할 때 서버에서 실행할 수 있는 코드를 다운로드하는 기능 (예: JavaScript 코드)
   • 하지만 대부분의 RESTful API에서는 필수 요소가 아니다.

---

🌟 RESTful API의 구성 요소

RESTful API는 리소스(Resource)를 중심으로 설계되며, HTTP 표준을 활용한다.

1. 자원(Resource)
   URI(Uniform Resource Identifier)를 통해 식별된다.
   • 예제

     https://api.example.com/users/123

     • /users/123 : ID가 123인 사용자 정보를 의미

2. HTTP 메서드
   RESTful API는 HTTP 메서드를 사용하여 CRUD(Create, Read, Update, Delete) 작업을 수행한다.

   HTTP 메서드	목적	설명
   GET	조회(Read)	데이터를 조회
   POST	생성(Create)	새로운 데이터를 생성
   PUT	전체 수정(Update)	특정 리소스를 전체 업데이트
   PATCH	부분 수정(Update)	특정 리소스를 부분 업데이트
   DELETE	삭제(Delete)	특정 리소스를 삭제

   • 예제: /users/123 자원에 대해 수행할 수 있는 작업
     • GET /users/123 : ID가 123인 사용자 정보 조회
     • POST /users : 새로운 사용자 생성
     • PUT /users/123 : ID가 123인 사용자 정보 전체 수정
     • PATCH /users/123 : ID가 123인 사용자 정보 일부 수정
     • DELETE /users/123 : ID가 123인 사용자 삭제

---

🌟 RESTful API의 설계 원칙 (Best Practices)

1. 명확하고 일관된 URI 설계
   • 리소스를 표현하는 명사 사용 (동사 X)

     ❌ /getUser
     ✅ /users/{ID}

   • 복수형을 사용하여 일관성 유지

     ❌ /user
     ✅ /users

   • 계층 구조를 반영하여 URI 설계

     ✅ /users/{id}/orders ➡️ 특정 사용자의 주문 목록 조회

2. HTTP 상태 코드(Status Code) 활용
   RESTful API는 적절한 HTTP 상태 코드를 반환해야 한다.

   상태 코드	의미	설명
   200 OK	성공	요청이 성공적으로 처리됨
   201 Created	생성 완료	새로운 리소스가 생성됨
   204 No Content	성공 (응답 본문 없음)	요청 성공, 하지만 반환할 데이터 없음
   400 Bad Request	잘못된 요청	클라이언트 요청이 잘못됨
   401 Unauthorized	인증 실패	인증되지 않은 사용자
   403 Forbidden	접근 거부	권한이 없음
   404 Not Found	리소스 없음	요청한 자원이 존재하지 않음
   409 Conflict	충돌 발생	중복된 데이터 또는 충돌 발생
   500 Internet Server Error	서버 오류	서버 내부 오류

   • 예제
     • GET /users/99999 (존재하지 않는 사용자) → 404 Not Found
     • POST /users (필수 필드 누락) → 400 Bad Request
     • DELETE /users/123 (삭제 성공) → 204 No Content

3. JSON을 기본 응답 형식으로 사용
   대부분의 RESTful API는 JSON을 사용하여 데이터를 주고받는다.
   • 응답 예제

     {
       "id": 123,
       "name": "홍길동",
       "email": "hong@example.com"
     }

   • 응답 헤더에 JSON 명시

     Content-Type: application/json

4. 필터링, 정렬, 페이징 지원
   대량의 데이터를 다룰 경우 필터링, 정렬, 페이징이 필요하다.
   • 필터링: GET /users?role=admin
   • 정렬: GET /users?sort=name,desc
   • 페이징: GET /users?page=2&size=20

---

🌟 결론

RESTful API는 간결하고 확장성이 뛰어나며, HTTP 표준을 활용하여 효과적인 클라이언트-서버 통신을 제공한다.
올바른 RESTful API 설계를 위해서는 URI 명명 규칙, HTTP 메서드 활용, 상태 코드 반환, JSON 응답 형식 등의 원칙을 잘 따르는 것이 중요하다.