RESTful API 정리

RESTful API

• RESTful API는 두 컴퓨터 시스템이 인터넷을 통해 정보를 안전하게 교환하기 위해 사용하는 인터페이스

---

API

• 애플리에이션 프로그래밍 인터페이스(API)는 다른 소프트웨어 시스텀과 통신하기 위해 따라야 하는 규칙을 정의
• API는 클라이언트와 리소스 사이의 게이트웨이

클라이언트

• 정보에 엑세스하려는 사용자.
• 클라이언트는 API를 사용하는 사람이거나 소프트웨어 시스템

리소스

• 다양한 애플리케이션이 클라이언트에게 제공하는 정보

---

 

REST

• Representational State Transfer(REST)는 API 작동 방식에 대한 조건을 부과하는 소프트웨어 아키텍처
• API 개발자는 여러 아키텍처를 사용하여 API를 설계할 수 있습니다. REST 아키텍처 스타일을 따르는 API를 REST API
• REST 아키텍처 스타일의 몇 가지 원칙
  • 1. 균일한 인터페이스
    • 요청은 리소스를 식별해야 합니다. 이를 위해 균일한 리소스 식별자를 사용
    • 클라이언트는 원하는 경우 리소스를 수정하거나 삭제하기에 충분한 정보를 리소스 표현에서 가지고 있다. 서버는 리소스를 자세히 설명하는 메타데이터를 전송하여 이 조건을 충족
    • 클라이언트는 표현을 추가로 처리하는 방법에 대한 정보를 수신 이를 위해 서버는 클라이언트가 리소스를 적절하게 사용할 수 있는 방법에 대한 메타데이터가 포함된 명확한 메시지를 전송
    • 클라이언트는 작업을 완료하는 데 필요한 다른 모든 관련 리소스에 대한 정보를 수신 이를 위해 서버는 클라이언트가 더 많은 리소스를 동적으로 검색할 수 있도록 표현에 하이퍼링크를 넣어 전송
  • 2. 무상태
    • REST 아키텍처에서 무상태는 서버가 이전의 모든 요청과 독립적으로 모든 클라이언트 요청을 완료하는 통신 방법
  • 3. 계층화 시스템
    • 클라이언트 요청을 이행하기 위해 함께 작동하는 보안, 애플리케이션 및 비즈니스 로직과 같은 여러 계층으로 여러 서버에서 실행되도록 RESTful 서비스를 설계할 수 있다
    • 이러한 계층은 클라이언트에 보이지 않는 상태로 유지
  • 4. 캐시 가능성
    • RESTful 서비스는 서버 응답 시간을 개선하기 위해 클라이언트 또는 중개자에 일부 응답을 저장하는 프로세스인 캐싱을 지원
  • 5. 온디맨드 코드
    • REST 아키텍처 스타일에서 서버는 소프트웨어 프로그래밍 코드를 클라이언트에 전송하여 클라이언트 기능을 일시적으로 확장하거나 사용자 지정할 수 있다

---

RESTful API를 사용할 때 이점

• 1. 확장성
  • REST API를 구현하는 시스템은 REST가 클라이언트-서버 상호 작용을 최적화하기 때문에 효율적으로 크기 조정
  • 무상태는 서버가 과거 클라이언트 요청 정보를 유지할 필요가 없기 때문에 서버 로드를 제거
  • 잘 관리된 캐싱은 일부 클라이언트-서버 상호 작용을 부분적으로 또는 완전히 제거
  • REST 아키텍처의 원칙으로 성능을 저하시키는 통신 병목 현상을 일으키지 않으면서 확장성을 지원
• 2. 유연성
  • RESTful 서비스는 완전한 클라이언트-서버 분리를 지원
  • 각 부분이 독립적으로 발전할 수 있도록 다양한 서버 구성 요소를 단순화하고 분리
  • 서버 애플리케이션의 플랫폼 또는 기술 변경은 클라이언트 애플리케이션에 영향을 주지 않음
  • 애플리케이션 함수를 계층화하는 기능은 유연성을 더욱 향상
• 3. 독립성
  • REST API는 사용되는 기술과 독립적
  • API 설계에 영향을 주지 않고 다양한 프로그래밍 언어로 클라이언트 및 서버 애플리케이션을 모두 작성가능
  • 통신에 영향을 주지 않고 양쪽의 기본 기술을 변경 가능

---

RESTful API의 작동 방식

1. 클라이언트가 서버에 요청을 전송 클라이언트가 API 문서에 따라 서버가 이해하는 방식으로 요청 형식을 지정
2. 서버가 클라이언트를 인증하고 해당 요청을 수행할 수 있는 권한이 클라이언트에 있는지 확인
3. 서버가 요청을 수신하고 내부적으로 처리
4. 서버가 클라이언트에 응답을 반환 응답에는 요청이 성공했는지 여부를 클라이언트에 알려주는 정보와 클라이언트가 요청한 모든 정보가 포함

---

RESTful API 클라이언트 요청의 구성 요소

• 고유 리소스 식별자
  • REST 서비스의 경우 서버는 일반적으로 URL(Uniform Resource Locator)을 사용하여 리소스 식별을 수행
  • URL은 리소스에 대한 경로를 지정
  • URL은 요청 엔드포인트라고도 하며 클라이언트가 요구하는 사항을 서버에 명확하게 지정
• 메서드
  • 4가지의 일반적인 HTTP 메서드
    • 1. GET
      • 클라이언트는 GET을 사용하여 서버의 지정된 URL에 있는 리소스에 액세스
      • GET 요청을 캐싱하고 RESTful API 요청에 파라미터를 넣어 전송하여 전송 전에 데이터를 필터링하도록 서버에 지시할 수 있다
    • 2. POST
      • 클라이언트는 POST를 사용하여 서버에 데이터를 전송
      • 요청과 함께 데이터 표현이 포함
      • 동일한 POST 요청을 여러 번 전송하면 동일한 리소스를 여러 번 생성하는 부작용
    • 3. PUT
      • 클라이언트는 PUT을 사용하여 서버의 기존 리소스를 업데이트
      • POST와 달리, RESTful 서비스에서 동일한 PUT 요청을 여러 번 전송해도 결과는 동일
    • 4. DELETE
      • 클라이언트는 DELETE 요청을 사용하여 리소스를 제거
      • DELETE 요청은 서버 상태를 변경할 수 있다
      • 사용자에게 적절한 인증이 없으면 요청은 실패
• HTTP 헤더
  • 요청 헤더는 클라이언트와 서버 간에 교환되는 메타데이터
  • 예를 들어, 요청 헤더는 요청 및 응답의 형식을 나타내고 요청 상태 등에 대한 정보를 제공
  • 데이터
    • REST API 요청에는 POST, PUT 및 기타 HTTP 메서드가 성공적으로 작동하기 위한 데이터가 포함될 수 있다
• 파라미터
  • RESTful API 요청에는 수행해야 할 작업에 대한 자세한 정보를 서버에 제공하는 파라미터가 포함될 수 있다
  • 몇 가지 파라미터 유형
    • URL 세부정보를 지정하는 경로 파라미터.
    • 리소스에 대한 추가 정보를 요청하는 쿼리 파라미터.
    • 클라이언트를 빠르게 인증하는 쿠키 파라미터.

---

RESTful API 인증 방법

• RESTful 서비스는 응답을 보내기 전에 먼저 요청을 인증해야 한다
• 클라이언트는 신뢰를 구축하기 위해 서버에 자신의 신원를 증명해야 한다
• 인증 방법
  • HTTP 인증
    • 기본 인증
      • 기본 인증에서 클라이언트는 요청 헤더에 사용자 이름과 암호를 넣어 전송
      • 안전한 전송을 위해 이 페어를 64자의 세트로 변환하는 인코딩 기술인 base64로 인코딩
    • 전달자 인증
      • 전달자(bearer) 인증이라는 용어는 토큰 전달자에 대한 액세스 제어를 제공하는 프로세스를 나타냄
      • 일반적으로 전달자 토큰은 서버가 로그인 요청에 대한 응답으로 생성하는 암호화된 문자열
      • 클라이언트는 리소스에 액세스하기 위해 요청 헤더에 토큰을 넣어 전송
  • API 키
    • 이 접근 방식에서 서버는 고유하게 생성된 값을 최초 클라이언트에 할당
    • 클라이언트는 리소스에 액세스하려고 할 때마다 고유한 API 키를 사용하여 본인을 검증
    • API 키의 경우 클라이언트가 이 키를 전송해야 해서 네트워크 도난에 취약하기 때문에 덜 안전
  • OAuth
    • OAuth는 모든 시스템에 대해 매우 안전한 로그인 액세스를 보장하기 위해 암호와 토큰을 결합
    • 서버는 먼저 암호를 요청한 다음 권한 부여 프로세스를 완료하기 위해 추가 토큰을 요청
    • 특정 범위와 수명으로 언제든지 토큰을 확인할 수 있다

---