◎ REST API란?
'제대로 보내고 받을 수 있는' 일종의 프로토콜 규약
“Representational State Transfer”의 약자 HTTP URI로 표현하고, HTTP 프로토콜을 통해 요청과 응답을 정의하는 방식
◎ 좋은 REST API를 디자인 하는 방법
REST API를 작성할 때는 몇 가지 지켜야 할 규칙들이 있습니다.
로이 필딩이 논문에서 제시한 REST 방법론을 보다 더 실용적으로 적용하기 위해
레오나르드 리차드슨은 REST API를 잘 적용하기 위한 4단계 모델을 만들었습니다.
-
0단계 : HTTP 프로토콜 사용
-
1단계 : 개별 리소스와의 통신을 준수
- REST API는 웹에서 사용되는 모든 데이터나
- 자원(Resource)을 HTTP URI로 표현한다.
- 그래서 개별 리소스에 맞는 엔드포인트(Endpoint)를 사용해야 하고
- 요청하고 받은 자원에 대한 정보를 응답으로 전달해야 한다.
-
2단계 : CRUD에 맞게 적절한 HTTP 메소드를 사용
| 메소드 | 내용 | 멱등성 여부 |
|---|---|---|
| GET | 서버의 데이터를 변화시키지 않는 요청에 사용 | O |
| POST | 요청마다 새로운 리소스를 생성 | X |
| PUT | 요청마다 같은 리소스를 반환 (교체) | O |
| PATCH | 수정 | X |
| DELETE | 삭제 | O |
■ REST 아키텍처 스타일의 몇 가지 원칙
◐ 균일한 인터페이스
균일한 인터페이스는 모든 RESTful 웹 서비스 디자인의 기본입니다. 이는 서버가 표준 형식으로 정보를 전송함을 나타냅니다.
형식이 지정된 리소스를 REST에서 표현이라고 부릅니다.
이 형식은 서버 애플리케이션에 있는 리소스의 내부 표현과 다를 수 있습니다.
예를 들어, 서버는 데이터를 텍스트로 저장하되, HTML 표현 형식으로 전송할 수 있습니다.
균일한 인터페이스를 위한 4가지 아키텍처 제약 조건
- 요청은 리소스를 식별해야 합니다. 이를 위해 균일한 리소스 식별자를 사용합니다.
- 클라이언트는 원하는 경우 리소스를 수정하거나 삭제하기에 충분한 정보를 리소스 표현에서 가지고 있습니다.
서버는 리소스를 자세히 설명하는 메타데이터를 전송하여 이 조건을 충족합니다. - 클라이언트는 표현을 추가로 처리하는 방법에 대한 정보를 수신합니다. 이를 위해 서버는 클라이언트가 리소스를 적절하게 사용할 수 있는 방법에 대한 메타데이터가 포함된 명확한 메시지를 전송합니다.
- 클라이언트는 작업을 완료하는 데 필요한 다른 모든 관련 리소스에 대한 정보를 수신합니다. 이를 위해 서버는 클라이언트가 더 많은 리소스를 동적으로 검색할 수 있도록 표현에 하이퍼링크를 넣어 전송합니다.
◐ 무상태
REST 아키텍처에서 무상태는 서버가 이전의 모든 요청과 독립적으로 모든 클라이언트 요청을 완료할 수 있다.
◐ 계층화 시스템
계층화된 시스템 아키텍처에서 클라이언트는 클라이언트와 서버 사이의 다른 승인된 중개자에게 연결할 수 있으며
여전히 서버로부터도 응답을 받습니다. 서버는 요청을 다른 서버로 전달할 수도 있습니다.
클라이언트 요청을 이행하기 위해 함께 작동하는 보안, 애플리케이션 및 비즈니스 로직과 같은 여러 계층으로 여러 서버에서 실행되도록 RESTful 웹 서비스를 설계할 수 있습니다. 이러한 계층은 클라이언트에 보이지 않는 상태로 유지됩니다.
◐ 캐시 가능성
RESTful 웹 서비스는 서버 응답 시간을 개선하기 위해 클라이언트 또는 중개자에 일부 응답을 저장하는 프로세스인 캐싱을 지원합니다.
예를 들어 모든 페이지에 공통 머리글 및 바닥글 이미지가 있는 웹 사이트를 방문한다고 가정해 보겠습니다.
새로운 웹 사이트 페이지를 방문할 때마다 서버는 동일한 이미지를 다시 전송해야 합니다.
이를 피하기 위해 클라이언트는 첫 번째 응답 후에 해당 이미지를 캐싱하거나 저장한 다음 캐시에서 직접 이미지를 사용합니다.
RESTful 웹 서비스는 캐시 가능 또는 캐시 불가능으로 정의되는 API 응답을 사용하여 캐싱을 제어합니다.
◐ 온디맨드 코드
REST 아키텍처 스타일에서 서버는 소프트웨어 프로그래밍 코드를 클라이언트에 전송하여 클라이언트 기능을 일시적으로 확장하거나 사용자 지정할 수 있습니다. 예를 들어, 웹 사이트에서 등록 양식을 작성하면 브라우저는 잘못된 전화번호와 같은 실수를 즉시 강조 표시합니다. 서버에서 전송한 코드로 인해 이 작업을 수행할 수 있습니다.
■ RESTful API의 이점
◐ 확장성
REST API를 구현하는 시스템은 REST가 클라이언트-서버 상호 작용을 최적화하기 때문에 효율적으로 크기 조정할 수 있습니다. 무상태는 서버가 과거 클라이언트 요청 정보를 유지할 필요가 없기 때문에 서버 로드를 제거합니다. 잘 관리된 캐싱은 일부 클라이언트-서버 상호 작용을 부분적으로 또는 완전히 제거합니다. 이러한 모든 기능은 성능을 저하시키는 통신 병목 현상을 일으키지 않으면서 확장성을 지원합니다.
◐ 유연성
RESTful 웹 서비스는 완전한 클라이언트-서버 분리를 지원합니다. 각 부분이 독립적으로 발전할 수 있도록 다양한 서버 구성 요소를 단순화하고 분리합니다. 서버 애플리케이션의 플랫폼 또는 기술 변경은 클라이언트 애플리케이션에 영향을 주지 않습니다. 애플리케이션 함수를 계층화하는 기능은 유연성을 더욱 향상시킵니다. 예를 들어, 개발자는 애플리케이션 로직을 다시 작성하지 않고도 데이터베이스 계층을 변경할 수 있습니다.
◐ 독립성
REST API는 사용되는 기술과 독립적입니다. API 설계에 영향을 주지 않고 다양한 프로그래밍 언어로 클라이언트 및 서버 애플리케이션을 모두 작성할 수 있습니다. 또한 통신에 영향을 주지 않고 양쪽의 기본 기술을 변경할 수 있습니다.
■ RESTful API 인증 방법이란 무엇인가요?
◐ HTTP 인증
HTTP는 REST API를 구현할 때 직접 사용할 수 있는 일부 인증 체계를 정의합니다. 다음은 이러한 체계 중 두 가지입니다.
-
기본 인증
기본 인증에서 클라이언트는 요청 헤더에 사용자 이름과 암호를 넣어 전송합니다. 안전한 전송을 위해 이 페어를 64자의 세트로 변환하는 인코딩 기술인 base64로 인코딩합니다. -
전달자 인증
전달자(bearer) 인증이라는 용어는 토큰 전달자에 대한 액세스 제어를 제공하는 프로세스를 나타냅니다. 일반적으로 전달자 토큰은 서버가 로그인 요청에 대한 응답으로 생성하는 암호화된 문자열입니다. 클라이언트는 리소스에 액세스하기 위해 요청 헤더에 토큰을 넣어 전송합니다.
◐ API 키
API 키는 REST API 인증을 위한 또 다른 옵션입니다. 이 접근 방식에서 서버는 고유하게 생성된 값을 최초 클라이언트에 할당합니다.
클라이언트는 리소스에 액세스하려고 할 때마다 고유한 API 키를 사용하여 본인을 검증합니다.
API 키의 경우 클라이언트가 이 키를 전송해야 해서 네트워크 도난에 취약하기 때문에 덜 안전합니다.
◐ OAuth
OAuth는 모든 시스템에 대해 매우 안전한 로그인 액세스를 보장하기 위해 암호와 토큰을 결합합니다.
서버는 먼저 암호를 요청한 다음 권한 부여 프로세스를 완료하기 위해 추가 토큰을 요청합니다.
특정 범위와 수명으로 언제든지 토큰을 확인할 수 있습니다.
