REST & REST API?

• REST(Representational State Transfer)
  • 웹 아키텍처의 일종
• REST API
  • REST 의 원칙을 기반으로 설계한 API
  • REST API 와 RESTful API 는 같은 의미로 사용할 수 있다

REST 원칙

다음과 같은 원칙을 따른 설계를 해야 RESTful API 라고 부를 수 있다.

1. 균일한 인터페이스

→ 응답/요청에 대한 표시정보가 균일해야 한다.

• URI 를 사용하여 리소스를 식별 & 명시한다.

  // 프로토콜 + URI 가 바로 URL!
  const response = await fetch('https://133.241.53.53');

• 리소스는 여러 표현(타입)을 가질 수 있다. XML 이나 JSON 등이 대표적이다.
• 서버는 클라이언트에게 리소스 표현을 처리하기 위한 메세지를 보낸다.
  • 리소스가 무엇인지
  • 리소스로 어떤 작업을 할 수 있는지
• 받은 리소스와 관련한 작업을 처리할 수 있도록 추가 정보를 수신 & 제공한다
  • 하이퍼링크를 통해 다음 동작 진행

2. 무상태

→ 각각의 요청은 독립적이어야 한다.

• 서버는 각 요청을 이전의 요청이나 다음 요청에 기반하여 처리하지 않아야 한다.

3. 계층화 시스템

→ 필요 시 다른 계층을 추가할 수 있다.

• 클라이언트와 서버 사이에 보안 & 어플리케이션 & 비즈니스 로직 등의 계층을 추가할 수 있다.

4. 캐시 가능성

→ 캐싱을 지원한다.

• 서버는 응답 시간을 개선하기 위해 응답을 저장하는 캐싱을 지원한다.

5. 온디멘드 코드

→ 서버는 클라이언트의 로직을 일시적으로 확장할 수 있다.

• 실시간으로 이메일 중복 검사를 하거나, 번호 유효성 검사를 한다거나…

RESTful API 동작

일반적인 인터넷 브라우징과 동일하게 동작한다. 이때 API 개발자는 서버 어플리케이션 API 문서에 클라이언트가 어떻게 API 를 사용해야 하는지 명시한다.

동작 순서

1. 클라이언트 → 서버로 API 방식에 따라 리소스 요청
2. 서버는 클라이언트를 인증 & 권한 확인
3. 서버는 요청을 수신하고 처리
4. 서버 → 클라이언트로 응답을 전송

클라이언트 요청 시 포함 요소

1. 고유 리소스식별자

URI 로 리소스를 고유하게 식별해야 한다.

2. 메서드

리소스에 수행하는 작업을 알려주는 HTTP 메서드

3. HTTP 헤더

• 요청에 대한 정보
• 데이터 (POST, PUT 등의 메서드 요청 시)
• 파라미터 (경로, 추가 데이터 요청, 쿠키 인증 등)

서버 응답 시 포함 요소

1. 상태표시줄

응답의 성공/실패를 HTTP 상태 코드로 알려줘야 한다.

2. 메세지 본문

리소스를 포함한 요청을 처리한 정보들을 전송한다.

3. 헤더

응답에 대한 헤더 정보.
메타데이터(인코딩 정보, 날짜 및 컨텐츠 유형 등)를 포함하고 있다.

REST API 인증

클라이언트는 서버에 요청을 보낼 때 보안 및 신뢰를 위해 자신의 신원을 증명해야 한다. 4가지 방법이 사용된다.

1. HTTP 인증

1. 기본 인증

   헤더에 사용자 암호와 이름을 넣어 인코딩 후 전송한다.

2. 전달자 인증

   bearer 토큰을 사용한 방식.

   클라이언트가 요청을 보내면 서버가 응답으로 보내준 인증용 토큰을 헤더에 넣어서 전송한다.

2. API 키

서버에서 고유하게 생성한 값을 최초 클라이언트에게 할당한다. 리소스 접근 시마다 API 키를 클라이언트가 전송해야 한다.

3. OAuth

암호와 토큰을 둘 다 요구하여 강력한 인증방식. 암호를 요청한 다음 추가적으로 토큰을 요청한다.