CS

[REST API] REST API 개념, 구성요소, 특징, RESTful API

Se On 2024. 11. 24. 23:32

📒 KEY POINT

💻 REST API란?
1. 웹 서비스간 데이터와 기능을 교환하기 위한 아키텍처 스타일
: 아키텍처 - 애플리케이션을 설계, 제작하는데 사용하는 패턴과 기술을 총칭합니다.
 2. HTTP 요청을 통해 작동
3. 자원을 URI로 식별, HTTP 메서드(GET, POST, PUT, DELETE 등)을 사용하여 해당 자원에 대한 작업 수행

✏️ REST, API 개념

✅ API

  • TV → 리모콘으로 켜고 끄고 조절, 모니터로 내용을 확인하는 것 ⇒ 인터페이스
  • 날씨가 궁금하면 기상청 서버 ↔ 정보 요청, 전송
    ⇒ 소프트웨어가 다른 소프트웨어로부터 지정된 형식으로 요청 및 명령을 받을 수 있는 수단: API(Application Programming Interface)

 

✅ REST + API

💻자원(Resource)의 표현(Representation)에 의한 상태 전달
- 자원: 해당 소프트웨어가 관리하는 모든 것(문서, 그림, 데이터 등)
- 표현: 그 자원을 표현하기 위한 이름(DB의 학생 정보가 자원이면 student)
- 상태 전달: 데이터가 요청되는 시점에 자원의 상태(JSON, xml)
  • 네트워크 상에서 Client와 Server 사이의 통신 방식 중 하나
  • 과거의 SOAP 형식을 대체한 것입니다.
  • 각 요청이 어떤 동작이나 정보에 의한 것인지, 그 요청 자체의 모습으로 추론 가능합니다.
    • 자원을 구조와 함께 나타내는 구분자: URI(통합 자원 식별자, Uniform Resource Identifier)
  • 서버에 REST API로 요청을 보낼 때는 HTTP 규약에 따라 신호를 전송합니다.

✏️ REST 구성요소

✅자원: URI

  • Client는 URI를 이용해 자원을 지정합니다.
  • 해당 자원의 상태에 대한 조작을 Server에 요청합니다.

 

✅행위: Method

  • 대표적인 메소드(HTTP 프로토콜의 Method 사용): get, post, delete, put, patch
    종류 설명(CRUD)
    GET Read, 정보 요청, URI가 가진 정보를 검색하기 위해 서버에 요청
    POST Creat, 정보 입력, 클라이언트에서 서버로 전달하려는 정보를 보냄
    PUT Update, 정보 업데이트, 주로 데이터 전체를 바꿀 때 사용
    PATCH Update, 정보 업데이트, 주로 데이터 일부만 바꿀 때 사용
    DELETE Delete, 정보 삭제, 안전 문제로 대부분 서버에서 비활성화
    • 그중 post, put, patch는 body가 있어서 get이나 delete보다 많이, 비교적 안전하게 감춰서 실어보낼 수 있습니다.

 

✅표현: Representation of resourse

  • Client와 Server가 데이터를 주고받는 형태: JSON, XML, TEXT, RSS 등
  • JSON, XML을 통해 데이터를 주고받는 것이 일반적입니다.

✏️ REST 특징

💻 Server-Client, Stateless, Cacheable, Layered System, Uniform Interface, Self-Descriptiveness
  • Server-Client: 서버 클라이언트 구조
    • 자원이 있는 쪽이 Server, 요청하는 쪽이 Client
    • 역할이 확실히 구분되어 있어서 서로 간 의존성을 줄입니다.
    • Server: API 제공, 비즈니스 로직 처리 및 저장합니다.
    • Client: 사용자 인증, context(세션 및 로그인 정도) 등을 직접 관리, 책임집니다.
  • Statelesee: 무상태
    • Clinet의 context(세션, 쿠키 등)를 Server에 저장하지 않습니다.
    • Server의 각 요청을 완전히 별개의 것으로 인식하고 처리합니다.
      • 각 API 서버는 Client의 요청을 단순 처리합니다.
      • 이전 요청이 다음 요청 처리에 연관되어서는 안 됩니다.(DB에 의해 바뀌는 것은 허용)
  • Cacheable: 캐시 처리 기능
    • 웹 표준 HTTP 프로토콜을 그대로 사용 → 웹에서 사용하는 기존의 인프라 그대로 활용 가능합니다.
      (따라서 캐싱 기능 적용 가능)
    • 대량의 요청을 효율적으로 처리할 수 있습니다.
  • Layered System: 계층 구조
    • Client는 REST API Server만 호출합니다.
    • REST Server는 다중 계층으로 구성되어 있습니다.
      • 보안, 로드 밸런싱, 암호화 등 → 계층 추가하여 구조를 변경합니다.
      • Proxy, Gateway와 같은 네트워크 기반의 중간매체 사용할 수 있습니다.
      • 하지만 Client는 Server와 직접 통신하는지, 중간 서버와 통신하는지 알 수 없습니다.
  • Uniform Interface: 인터페이스 일관성
    • URI로 지정한 Resource에 대한 요청 통일, 한정적으로 수행하는 아키텍처 스타일입니다.
    • HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용할 수 있습니다.
    • Loosely Coupling(느슨한 결함) 형태를 갖습니다.
      • 즉, 특정 언어나 기술에 종속되지 않습니다.
  • Self-Descriptiveness: 자체 표현
    • 요청 메세지만 보고도 쉽게 이해할 수 있는 자체 표현 구조로 되어 있습니다.

✏️ REST API

💻REST API
- URI = 정보의 자원을 표현한다 
- 자원에 대한 행위 = HTTP Method(GET, POST, PUT, PATCH, DELETE)
  • 정의: 위와 같은 REST의 특징을 기반으로 서비스 API를 구현한 것입니다.
  • 특징: REST API의 가장 큰 특징 = 각 요청이 어떤 동작이나 정보를 위한 것인지, 그 요청의 모습 자체로 추론 가능 (Self-Descriptiveness)
  • REST API 설계 규칙 
    1. URI: 명사 + 소문자로 구성한다 (get~, create~, update~ 금지)
    2. 계층관계: /
    3. URI 마지막 문자로 슬래시(/)를 포함하지 않는다
    4. 밑줄 x, 하이픈 o을 사용한다
    5. HTTP 응답 상태 코드 사용
      • 1xx: 정보응답, 2xx: 성공응답, 3xx: 리다이렉트, 4xx: 클라이언트 요청오류, 5xx: 서버오류
    6. 파일확장자는 URI에 포함하지 않는다

✏️ RESTful API

  • RESTful: REST의 설계 규칙을 잘 지켜서 설계된 API

💭 Q&A

🔎 질문 1: REST API란 무엇인가요?

  • 답변
    • REST API는 "Representational State Transfer"의 약자
    • 웹 서비스 간에 데이터와 기능을 교환하기 위해 사용하는 아키텍처 스타일입니다.
    • HTTP 요청을 통해 작동하며 자원을 URI(Uniform Resource Identifier)로 식별하고, HTTP 메서드(GET, POST, PUT, DELETE 등)를 사용하여 해당 자원에 대해 작업을 수행합니다.

 

🔎 질문 2: REST와 RESTful의 차이는 무엇인가요?

  • 답변
    • REST는 아키텍처 스타일 또는 패러다임을, RESTful은 이 스타일을 따르는 API를 의미합니다.
    • RESTful API는 REST의 원칙(무상태성, 클라이언트-서버 아키텍처, 캐시 가능성 등)을 준수하여 설계된 API입니다.
    • 즉, RESTful은 REST의 개념을 실질적으로 구현한 API를 지칭할 때 사용됩니다.

 

🔎 질문 3: REST API의 6가지 제약 조건에 대해 설명해주세요.

  • 답변
    1. 클라이언트-서버 구조: 클라이언트와 서버는 분리된 구조로 클라이언트는 사용자 인터페이스를, 서버는 데이터 저장 및 처리 역할을 담당합니다.
    2. 무상태성: 서버는 각 요청을 독립적으로 처리하며 이전 요청과의 상태를 유지하지 않습니다.
    3. 캐시 가능성: 응답 데이터는 캐시될 수 있어야 하며 캐시 가능한 데이터와 캐시 불가능한 데이터를 명확히 구분해야 합니다.
    4. 계층화 시스템: 클라이언트는 여러 중간 계층(프록시, 게이트웨이 등)을 통해 서버에 접근할 수 있습니다.
    5. 선택적: 서버는 클라이언트에게 스크립트를 전송하여 실행할 수 있게 할 수 있습니다.
    6. 인터페이스의 일관성: API 설계는 일관된 인터페이스를 가져야 하며 이는 자원의 구조를 직관적으로 이해할 수 있게 도와줍니다.

 

🔎 질문 4: HTTP 메서드와 그 역할에 대해 설명해주세요.

  • 답변
    • GET: 서버에서 자원의 표현을 요청합니다. 데이터를 가져올 때 사용됩니다.
    • POST: 서버에 자원을 생성하거나 데이터를 제출할 때 사용됩니다.
    • PUT: 서버에 자원을 업데이트할 때 사용됩니다. 자원이 없으면 새로 생성할 수 있습니다.
    • DELETE: 서버에서 자원을 삭제할 때 사용됩니다.
    • PATCH: 자원의 일부를 업데이트할 때 사용됩니다.

 

🔎 질문 5: RESTful API 설계 시 주의해야 할 점은 무엇인가요?

  • 답변:
    1. URI 설계: 직관적이고 명확한 URI를 설계해야 합니다. GET /users/123는 ID가 123인 사용자를 가져오는 URI입니다.
    2. HTTP 상태 코드 사용: 응답 시 적절한 HTTP 상태 코드를 반환해야 합니다. 요청이 성공하면 200 OK, 자원이 생성되면 201 Created 등을 반환합니다.
    3. 무상태성 준수: 각 요청은 독립적으로 처리되며 서버는 클라이언트의 상태를 유지하지 않도록 해야 합니다.
    4. 응답 포맷: JSON이나 XML과 같은 통일된 응답 포맷을 사용하여 클라이언트가 응답을 쉽게 처리할 수 있도록 해야 합니다.
    5. 보안: API 키, OAuth와 같은 인증 및 인가 방식을 사용해 보안을 강화해야 합니다.

 

🔎 질문 6: REST API의 단점은 무엇인가요?

  • 답변
    1. 복잡한 쿼리: 복잡한 데이터 조회에는 REST API가 비효율적일 수 있습니다. GraphQL 같은 대안이 유리할 수 있습니다.
    2. 무상태성으로 인한 데이터 중복: 요청이 독립적으로 처리되므로, 동일한 클라이언트에 대해 중복된 데이터를 전송해야 할 수 있습니다.
    3. 오버페칭/언더페칭: 클라이언트가 필요한 데이터보다 더 많거나 적게 가져오게 되는 경우가 발생할 수 있습니다.

참고자료

  •  
반응형