게으른개발너D

RESTful API 본문

CS

RESTful API

lazyhysong 2024. 1. 21. 17:35

1. RESTful API

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

 

1.1 API

API (Application Programming Interface)는 다른 소프트웨어 시스템과 통신하기 위해 따라야하는 규칙을 정의한다.

개발자는 다른 애플리케이션이 프로그래밍 방식으로 애플리케이션과 통신할 수 있도록 API를 표시하거나 생성한다.

웹 API는 클라이언트와 웹 리소스 사이의 gateway(출입구, 통로)라고 할 수 있다.

1.1.1 클라이언트

클라이언트는 웹에서 정보에 접근하려는 사용자이다.

클라이언트는 API를 사용하는 사람이거나 소프트웨어 시스템일 수 있다.

1.1.2 리소스

리소스는 다양한 애플리케이션이 클라이언트에게 제공하는 정보이다. 리소스는 이미지, 영상, 텍스트, 숫자 또는 모든 유형의 데이터일 수 있다.

클라이언트에 리소스를 제공하는 시스템을 서버라고 한다.

 

1.2 REST

REST(Representational State Transfer)는 API 작동 방식에 대한 조건을 부과하는 소프트웨어 아키텍처이다.

REST는 처음에 인터넷과 같은 복잡한 네트워크에서 통신을 관리하게 위한 지침으로 만들어졌다.

대규모의 고성능 통신을 안정적으로 지원할 수 있고 쉽게 구현하고 수정할 수 있어 모든 API 시스템을 파악하고 여러 플랫폼에서 사용할 수 있다.

 

REST 아키텍처 스타일을 따르는 APIREST API라고 한다. 

REST 아키텍처를 구현하는 웹 서비스RESTful 웹 서비스라고 한다. 따라서 RESTful API는 RESTful 웹 API를 나타낸다.

하지만 REST API와 RESTful API는 같은 의미로 사용할 수 있다.

1.2.1 REST 아키텍처 스타일의 몇 가지 원칙

1. 균일한 인터페이스

균일한 인터페이스는 모든 RESTful 웹 서비스 디자인의 기본이다. 이는 서버가 표준 형식으로 정보를 전송함을 나타낸다.

형식이 지정된 리소스를 REST에서는 표현이라고 부른다. 

 

2. 무상태

REST 아키텍처에서 무상태는 서버가 이전의 모든 요청과 독립적으로 모든 클라이언트 요청을 완료하는 통신 방법을 나타낸다.

클라이언트는 임의의 순서로 리소스를 요청할 수 있으며 모든 요청은 무상태이거나 다른 요청과 분리된다.

 

3. 계층과 시스템

클라이언트는 클라이언트과 서버 사이의 다른 승인된 중개자에게 연결할 수 있다.

서버는 클라이언트 요청을 이행하기 위해 함께 작동하는 보안, 애플리케이션 및 비즈니스 로직과 같은 여러 계층으로 여러 서버에서 실행되도록 RESTful 웹 서비스를 설계할 수 있다.

 

4. 캐시 가능성

서버 응답 시간을 개선하기 위해 클라이언트 또는 중개자에 일부 응답을 저장하는 프로세스인 캐싱을 지원한다.

 

5. 온디맨드 코드

서버는 소프트웨어 프로그래밍 코드를 클라이언트에 전송하여 클라이언트 기능을 일시적으로 확장하거나 사용자 지정할 수 있다.

예를들어 등록 양식에서 잘못된 전화번호와 같은 실수를 즉시 강조 표시하는 것.

 

 

 

2. RESTful API 사용시 이점

2.1 확장성

REST가 클라이언트-서버 상호 작용을 최적화하기 때문에 효율적으로 크기 조정할 수 있다.

'무상태'로 인해 서버는 클라이언트의 이전 요청 정보를 유지할 필요가 없다.

'캐싱'으로 인해 일부 클라이언트-서버 상호작용을 부분적으로 또는 완전히 제거할 수 있다.

2.2 유연성

RESTful 웹 서비스는 완전한 클라이언트-서버 분리를 지원한다. 즉 서버의 플랫폼 또는 기술 변경은 클라이언트에 영향을 주지 않는다.

2.3 독립성

REST API는 사용되는 기술과 독립적이다. API 설계에 영향을 주지 않고 다양한 프로그래밍 언어로 클라이언트 및 서버 애플리케이션을 모두 작성할 수 있다. 또한 통신에 영향을 주지 않고 양쪽의 기본 기술을 변경할 수 있다.

 

 

 

3. RESTful API 작동 방법

RESTful API의 기본 기능을 인터넷 브라우징과 동일하다. 

 

1. 클라이언트가 서버에 요청을 한다. 클라이언트가 API 문서에 따라 서버가 이해하는 방식으로 요청 형식을 지정한다.

2. 서버가 클라이언트를 인증하고 클라이언트에 해당 요청을 수행할 수 있는 권한이 있는지 확인한다.

3. 서버가 요청을 수신하고 내부적으로 처리한다.

4. 서버가 클라이언트에 응답을 반환한다. 응답에는 요청의 성공여부와 클라이언트가 요청한 정보가 포함되어 있다.

 

 

 

4. RESTful API 클라이언트 요청에 포함된 주요 구성요소

4.1 고유 리소스 식별자

서버는 고유한 리소스 식별자로 각 리소스를 식별한다. 

REST 서비스의 경우 서버는 URL을 사용하여 리소스를 식별한다. URL은 리소스에 대한 경로를 지정한다.

4.2 Method

RESTful API는 일반적으로 HTTP(Hypertext Transfer Protocol)을 사용하여 구현한다. 

HTTP Method는 리소스에 수행해야 하는 작업을 서버에 알려준다.

1. GET

클라이언트는 GET을 사용하여 서버의 지정된 URL에 있는 리소스에 액세스한다.

2. POST

클라이언트는 POST를 사용하여 서버에 데이터를 전송한다. 여기에는 요청과 함께 데이터 표현이 포함된다.

3. PUT

클라이언트는 PUT을 사용하여 서버의 기존 리소스를 업데이트한다.

4. DELETE

클라이언트는 DELETE 요청을 사용하여 리소스를 제거합니다. DELETE 요청은 서버 상태를 변경할 수 있습니다.

4.3 HTTP Header

요청 헤더는 클라이언트와 서버 간에 교환되는 메타데이터이다.

예를 들어, 요청 헤더는 요청 및 응답의 형식을 나타내고 요청 상태 등에 대한 정보를 제공한다.

4.3.1 데이터

REST API 요청에는 POST, PUT 및 기타 HTTP 메서드가 성공적으로 작동하기 위한 데이터가 포함될 수 있다.

4.3.2 파라미터

수행해야 할 작업에 대한 자세한 정보를 서버에 제공하는 파라미터가 포함될 수 있다.

1. URL 세부정보를 지정하는 경로 파라미터

2. 리소스에 대한 추가 정보를 요청하는 쿼리 파라미터

3. 클라이언트를 빠르게 인증하는 쿠키 파라미터

 

 

5. RESTful API 인증 방법

RESTful 웹 서비스는 응답을 보내기 전에 먼저 요청을 인증해야 한다. 

RESTful API에는 4가지의 일반적인 인증 방법이 있습니다.

5.1 HTTP 인증

HTTP는 REST API를 구현할 때 직접 사용할 수 있는 일부 인증 체계를 정의한다. 

5.1.1 기본 인증

기본 인증에서 클라이언트는 요청 헤더에 사용자 이름과 암호를 넣어 전송한다. 안전한 전송을 위해 이 페어를 64자의 세트로 변환하는 인코딩 기술인 base64로 인코딩한다.

5.1.2 전달자 인증

전달자(bearer) 인증이라는 용어는 토큰 전달자에 대한 액세스 제어를 제공하는 프로세스를 나타낸다. 일반적으로 전달자 토큰은 서버가 로그인 요청에 대한 응답으로 생성하는 암호화된 문자열이다. 클라이언트는 리소스에 액세스하기 위해 요청 헤더에 토큰을 넣어 전송한다.

5.2 API Key

서버는 고유하게 생성된 key 값을 클라이언트에 할당한다. 클라이언트는 리소스에 액세스하려고 할 때마다 고유한 API 키를 사용하여 본인을 검증한다. 

5.3 OAuth

OAuth는 모든 시스템에 대해 매우 안전한 로그인 액세스를 보장하기 위해 암호와 토큰을 결합한다. 서버는 먼저 암호를 요청한 다음 권한 부여 프로세스를 완료하기 위해 추가 토큰을 요청한다. 

 

 

 

6. RESTful API 서버 응답

REST 원칙에 따라 서버 응답에 다음과 같은 주요 구성 요소를 포함해야 한다.

6.1 상태 표시줄 (State Line)

상태 표시줄에는 요청 성공 여부를 알리는 3자리 상태 코드가 있다. 

 

HTTP 상태 코드

Client(browser)에서 서버에 Request를 하면 서버는 Response를 보낸다. 적절한 처리가 이루어져서 성공 응답과 함께 결과 값을 보내주기도 하고, 정상적인 처리가 되지 않은 경우에는 실패 응답과 함께

lazyhysong.tistory.com

200: 성공 응답

201: POST 메서드 성공 응답

400: 서버가 처리할 수 없는 잘못된 요청

404: 리소르를 찾을 수 없음

6.2 메세지 본문 (Body)

응답 본문에는 리소스 표현이 포함된다.

서버는 요청 헤더에 포함된 내용을 기반으로 표현 형식을 선택한다. 표현 형식에는 XML과 JSON 형식이 있다.

6.3 헤더 (Header)

응답에는 응답에 대한 헤더 또는 메타데이터도 포함된다.

  • Host : 요청하려는 서버 호스트 이름과 포트번호
  • User-agent : 클라이언트 프로그램 정보. 이 정보를 통해 서버는 클라이언트 프로그램(브라우저)에 맞는 최적의 데이터를 보내줄 수 있다.
  • Referer : 바로 직전에 머물렀던 웹 링크 주소 
  • Accept : 클라이언트가 처리 가능한 미디어 타입 종류 나열
  • If-Modified-Since : 여기에 쓰여진 시간 이후로 변경된 리소스 취득. 페이지가 수정되었으면 최신 페이지로 교체한다.
  • Authorization : 인증 토큰을 서버로 보낼 때 쓰이는 Header
  • Origin : 서버로 Post 요청을 보낼 때 요청이 어느 주소에 시작되었는지 나타내는 값. 이 값으로 요청을 보낸 주소와 받는 주소가 다르면 CORS(Cross-Origin Resource Sharing) 에러가 발생한다.
  • Cookie : 쿠키 값이 key-value로 표현된다.

'CS' 카테고리의 다른 글

HTTP 상태 코드  (0) 2024.01.18
[Design Pattern] Flux 패턴  (1) 2023.09.02
[Design Pattern] Atomic 패턴  (0) 2023.09.02
컴퓨터 시간  (0) 2023.08.04
네트워크 기초  (0) 2023.08.04
Comments