Toby

[CS] Deep Dive to REST API

[CS] Deep Dive to REST API

Toby's photo
Toby

Table of contents

REST API를 이용한 서비스는 정말 많고

많은 기업에서 REST API 많이 써봤어 묻는다.

근데 약간 뭐랄까? 그래서 REST API가 뭐야? 라고 물어보면

어... 음.... HTTP를 이용한 통신 규격...? 밖에 말을 못하겠다.

그래서 알아보자

용어 정리

공부하다보면 REST / REST API / RESTful / RESTful 웹 서비스 / RESTful API 많다.

이 용어에 대한 정확한 분리를 하고 가자.

API

Application Programming Interface

다른 소프트웨어 프로그램과 통신하기 위해 따라야 하는 규칙.

REST

Representational State Transfer

API 작동 방식에 대한 조건을 부과하는 소프트웨어 아키텍처

즉, REST API란? REST 아키텍쳐를 따르는 타 소프트웨어와 통신하는 규칙이라고 생각하면 될것 같다.

REST 아키텍처 스타일을 따르는 API를 REST API

REST 아키텍처를 구현하는 웹 서비스를 RESTful 웹 서비스, RESTful API라는 용어는 일반적으로 RESTful 웹 API를 나타냅니다.

하지만 REST API와 RESTful API라는 용어는 같은 의미로 사용하는 경우가 많다.

그럼 REST 아키텍쳐는 어떤 원칙이 있을까?

  1. 균일한 인터페이스

    1. 요청은 리소스를 식별해야 합니다. 이를 위해 균일한 리소스 식별자를 사용합니다.

    2. 클라이언트는 원하는 경우 리소스를 수정하거나 삭제하기에 충분한 정보를 리소스 표현에서 가지고 있습니다. 서버는 리소스를 자세히 설명하는 메타데이터를 전송하여 이 조건을 충족합니다.

    3. 클라이언트는 표현을 추가로 처리하는 방법에 대한 정보를 수신합니다. 이를 위해 서버는 클라이언트가 리소스를 적절하게 사용할 수 있는 방법에 대한 메타데이터가 포함된 명확한 메시지를 전송합니다.

    4. 클라이언트는 작업을 완료하는 데 필요한 다른 모든 관련 리소스에 대한 정보를 수신합니다. 이를 위해 서버는 클라이언트가 더 많은 리소스를 동적으로 검색할 수 있도록 표현에 하이퍼링크를 넣어 전송합니다.

  2. 무상태

    1. 서버가 이전의 모든 요청과 독립적으로 모든 클라이언트 요청을 완료하는 통신 방법을 나타냅니다. 즉, 순서와 무관합니다.

  3. 계층화 시스템

    1. 계층화된 시스템 아키텍처에서 클라이언트는 클라이언트와 서버 사이의 다른 승인된 중개자에게 연결할 수 있으며 여전히 서버로부터도 응답을 받습니다. 즉 서버사이드측에서 다른 서버에 요청하며 계층화되게 관리될 수 있고, 클라이언트 측에서는 해당 사항이 보이지 않는 상태로 유지됩니다.

  4. 캐시 가능성

    1. 서버 응답시간 개선을 위해 클라이언트 또는 중개자에 일부 응답을 저장하는 캐시를 지원합니다.

  5. 온디맨드 코드 (Optional)

    1. 이 말은 우리가 평소에는 정적인 데이터를 xml 또는 json에 담아서 client로 보내고 client가 이것을 가공합니다. 하지만 code on demand라는 것은 client에 보내는 데이터를 바로 실행 가능한 코드를 보내서 이것을 Client에서 실행하는 것을 말합니다. (Server-Driven)

REST API에는 어떤 요청이 들어가 있을까?

고유 리소스 식별자

우리가 흔히 이야기하는 Path, 경로를 뜻한다. 클라이언트 요구사항을 서버에 명확하게 지정한다.

메소드

리소스에 수행해야 하는 작업을 서버에 알려주는 역할

  1. GET

서버에 지정된 URL에 있는 리소스에 접근하는 역할. 파라미터를 넣어 전송 전에 데이터 필터링도 가능하다.

  1. POST

서버에 데이터를 전송하는 역할. 요청과 함께 데이터 표현 방식이 포함되어 있다.

동일한 POST 요청을 여러번하면 동일한 리소스를 발생하는 부작용이 있다.

  1. PUT

기존 리소스를 업데이트 한다. POST와 달리 RESTful 웹 서비스에서 동일한 PUT 요청을 해도 결과는 동일하다.

  1. PATCH

기존 리소스 중 일부분만 수정할 때 사용하게 된다.

  • POST / PUT / PATCH의 차이점에 대해서 링크

  1. DELETE

리소스를 제거하는 역할. 사용자에게 적절한 인증이 없으면 요청을 실패함

HTTP 헤더

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

예를 들어 어떤 encoding 방식으로 데이터를 전송할 것인지 메타데이터에 기입할 수 있다.

RESTful API 인증 방법

HTTP 인증

  1. 기본인증

헤더에 사용자의 이름과 암호를 넣어서 base64로 인코딩하여 전송하는 방법

  1. 전달자 인증

Bearer 인증이라고도 하며 토큰 전달자에 대한 액세스 제어를 제공하는 프로세스를 나타냄.

일반적으로 전달자 토큰은 서버가 로그인 요청에 대한 응답으로 생성하는 암호화된 문자열

리소스 엑세스 때 요청 헤더에 토큰을 넣어서 전송

API 키

서버는 고유하게 생성된 값을 최초 클라이언트에 할당합니다. 클라이언트는 리소스에 액세스하려고 할 때마다 고유한 API 키를 사용하여 본인을 검증합니다. API 키의 경우 클라이언트가 이 키를 전송해야 해서 네트워크 도난에 취약하기 때문에 덜 안전합니다.

OAuth

OAuth는 모든 시스템에 대해 매우 안전한 로그인 액세스를 보장하기 위해 암호와 토큰을 결합합니다. 서버는 먼저 암호를 요청한 다음 권한 부여 프로세스를 완료하기 위해 추가 토큰을 요청합니다. 특정 범위와 수명으로 언제든지 토큰을 확인할 수 있습니다.

Restful API 서버 응답

  • 200: 일반적인 성공 응답

  • 201: POST 메서드 성공 응답

  • 400: 서버가 처리할 수 없음

  • 404: NOT FOUND

참고했던 사이트

https://aws.amazon.com/ko/what-is/restful-api/

REST APIRESTrestful