s2-u8)REST API

REST API

API 또는 애플리케이션 프로그래밍 인터페이스는 애플리케이션이나 디바이스가 서로 간에 연결하여 통신할 수 있는 방법을 정의하는 규칙 세트, REST API는 REST(REpresentational State Transfer) 아키텍처 스타일의 디자인 원칙을 준수하는 API다

로이 필딩 (Roy Fielding)의 박사학위 논문에서 웹(http)의 장점을 최대한 활용할 수 있는 아키텍처로써 처음 소개되었고 REST API는 웹에서 사용되는 데이터나 자원(Resource)을 HTTP URI로 표현하고, HTTP 프로토콜을 통해 요청과 응답을 정의하는 방식이라 할 수 있다.

REST API 디자인 원칙

1. 균일한 인터페이스:요청이 어디에서 오는지와 무관하게, 동일한 리소스에 대한 모든 API 요청은 동일하게 보여야 합니다. REST API는 사용자의 이름이나 이메일 주소 등의 동일한 데이터 조각이 오직 하나의 URI(Uniform Resource Identifier)에 속함을 보장해야 합니다. 리소스가 너무 클 필요는 없지만, 이는 클라이언트가 필요로 하는 모든 정보를 포함해야 합니다.

2. 클라이언트-서버 디커플링: REST API 디자인에서, 클라이언트와 서버 애플리케이션은 서로 간에 완전히 독립적이어야 합니다. 클라이언트 애플리케이션이 알아야 하는 유일한 정보는 요청된 리소스의 URI이며, 이는 다른 방법으로 서버 애플리케이션과 상호작용할 수 없습니다. 이와 유사하게, 서버 애플리케이션은 HTTP를 통해 요청된 데이터에 전달하는 것 말고는 클라이언트 애플리케이션을 수정하지 않아야 합니다.

3. Stateless: REST API는 stateless입니다. 이는 각 요청에서 이의 처리에 필요한 모든 정보를 포함해야 함을 의미합니다. 즉, REST API는 서버측 세션을 필요로 하지 않습니다. 서버 애플리케이션은 클라이언트 요청과 관련된 데이터를 저장할 수 없습니다.

4. 캐싱 가능성 : 가급적이면, 리소스를 클라이언트 또는 서버측에서 캐싱할 수 있어야 합니다. 또한 서버 응답에는 전달된 리소스에 대해 캐싱이 허용되는지 여부에 대한 정보도 포함되어야 합니다. 이의 목적은 서버측의 확장성 증가와 함께 클라이언트측의 성능 향상을 동시에 얻는 것입니다.

5. 계층 구조 아키텍처 : REST API에서는 호출과 응답이 서로 다른 계층을 통과합니다. 일반적으로는, 클라이언트와 서버 애플리케이션이 서로 간에 직접 연결된다고 가정하지 마세요. 통신 루프에는 다수의 서로 다른 중개자가 있을 수 있습니다. REST API는 엔드 애플리케이션 또는 중개자와 통신하는지 여부를 클라이언트나 서버가 알 수 없도록 설계되어야 합니다.

6. 코드 온디맨드(옵션) : REST API는 일반적으로 정적 리소스를 전송하지만, 특정한 경우에는 응답에 실행 코드(예: Java 애플릿)를 포함할 수도 있습니다. 이러한 경우에, 코드는 요청 시에만 실행되어야 합니다.

   출처: https://www.ibm.com/kr-ko/cloud/learn/rest-apis#toc-rest---bdA-Cdl2

   REST API 성숙도 모델

   0단계

   0단계에서는 웹 메커니즘을 사용하지 않고 HTTP를 원격 통신을 위한 전송 시스템으로 사용하는 것이다.

   1단계

   1단계부터는 리소스를 도입한다. 레벨 0과 같이 요청 모두를 단일 서비스 엔드포인트로 보내는 것이 아닌 개별 리소스와 통신한다.

   2단계

   단계부터는 HTTP 사용법에 최대한 가깝게(CRUD에 맞게) HTTP 메서드를 이용하여 API를 구현한다.

   HTTP 메서드를 사용시 몇가지 규칙에 유의해야한다.

   GET 메서드 같은 경우는 서버의 데이터를 변화시키지 않는 요청에 사용해야 합니다.
   POST 메서드는 요청마다 새로운 리소스를 생성하고 PUT 메서드는 요청마다 같은 리소스를 반환합니다. 이렇게 매 요청마다 같은 리소스를 반환하는 특징을 멱등(idempotent)하다고 합니다. 그렇기 때문에 멱등성을 가지는 메서드 PUT과 그렇지 않은 메서드POST는 구분하여 사용해야 합니다.
   PUT 메서드와 PATCH 메서드도 구분하여 사용해야 합니다. PUT은 교체, PATCH는 수정의 용도로 사용합니다.

   3단계

   HATEOAS(Hypertext As The Engine Of Application state)라는 약어로 종종 언급되는 것을 도입하는 단계이다.
   3단계의 요청은 2단계와 동일하나 응답에는 리소스의 URI를 포함한 링크 요소를 삽입하여 작성해야 한다.

   이대 응답에 들어가게 되는 링크 요소는 응답을 받은 다음에 할 수 있는 다양한 액션들을 위해 많은 하이퍼미디어 컨트롤을 포함한다.

   OPEN API

   누구한테는 이용할 수 있도록 열려 있는 API로 이용 수칙에 따라 제한사항이 있을 수 있다.

   API KEY

   API를 이용하기 위해 필요한 KEY로 로그인한 이용자에게 자원에 접근할 수 있는 권한을 API KEY의 형태로 제공하고, 데이터를 요청할 대 API KEY를 같이 전단해야 원하는 응답을 받을 수 있다.