API란❓
“Application Programming Interface”의 약자
클라이언트, 서버와 같은 서로 다른 프로그램에서 어떠한 정보에 대하여 요청과 응답을 주고 받을 수 있게 만든 체계를 API라고 합니다.
다시말해, API는 “하나의 소프트웨어가 다른 소프트웨어로부터 지정된 형식으로 요청, 명령을 받을수 있는 수단”이라고 할 수 있습니다.
REST의 탄생 배경
REST는 1998년 당시 대학원생 신분이었던, “Roy T Fielding” 으로부터 시작됩니다.
Roy T Fielding 은 당시 HTTP/1.0 표준에 대해 기능을 적립하고, 명세에 기능을 더하며, 고치는 일을 하고 있었습니다.
이때 이미 점차 넓어지고 있는 웹 생태계에 문제를 끼치지 않고, HTTP를 발전 시킬 수 있을까 고민하면서 만들었던 것이 바로 “REST” 입니다.
REST → “Representational State Transfer”의 약자로 말 그대로 해석을 하면, 데이터 자원을 주고 받을 수 있도록 표현한 것이라고 생각하면 됩니다.
Roy T Fielding은 이것을 발표한 논문에서 이렇게 표현합니다.
분산 하이퍼미디어(WEB..)을 위한 아키텍처 스타일. 규칙과 제약조건
REST는 기존 HTTP Method, Status Code 등을 적극적으로 이용하며, 자원(Resource)에 고유한 URI을 할당해 사용하도록 만든 것이 특징입니다.
REST는 초기에는 큰 관심을 받지는 못했습니다. 그때 당시 많이 사용되고 있던 방식이 있었기 때문입니다.
당시 유행으로 사용되고 있던 SOAP라는 아키텍처 방식으로 API가 사용되고 있었습니다. 하지만, SOAP는 워낙 복잡하고, 사용하기 어려웠지만, REST 방식은 훨씬 직관적이고, 간단한 코드를 사용했습니다.
이후 AWS 등 API를 제공하던 대기업들이 REST를 사용하게 되면서 유행처럼 사용되기 시작합니다.
REST API란❓
REST라는 아키텍처, 제약 조건을 따르는 방식을 통해 만든 API를 “REST API”라고 합니다.
“REST 아키텍처의 제약조건을 따르는 API 방식”
2008년에 EMC, IBM, Microsoft가 함께 CMS를 표준화하면서 REST API에 대한 것을 문서화하기 시작하고, 2016년부터 매년 Microsoft가 REST API에 대한 표준 가이드라인을 제공하기 시작합니다.
그런데 정작 REST를 개발을 한 “Roy T Fielding”은 저건 REST API가 아니라고 이야기 하고 있답니다.ㅎ
REST API 사용
REST API를 사용하는 방법에는 크게 아래 두가지를 표현합니다.
- HTTP URI(Uniform Resource Identifier)'를 통해 자원(Resource)을 명시
- HTTP Method(POST, GET, PUT, DELETE, PATCH 등)'를 통해 해당 자원(URI)에 대한 'CRUD Operation'을 적용
HTTP URI 를 통해 자원(Resource)을 명시
URI(Uniform Resource Identifier)란?
“특정 리소스를 식별하는 식별자”를 의미한다.
흔히 우리가 아는 URL과는 다른 의미로, URL은 주소(Location)를 이야기 하는 것이라면, URI는 URL보다 조금 더 특정한 자원을 지칭하는 것 (Identifier)이라고 생각하면 됩니다.
REST API를 처음 개발할 때, 웹 생태계에 표준적으로 사용되고 있는 HTTP를 어떻게 사용할 수 있을까 고민했기에 이러한 HTTP URI 방식을 통해 자원을 명시하여 요청하고 있습니다.
//URL
https://www.exaple.com/
//URI
https://www.exaple.com/home/indexHTTP Method 를 통한 'CRUD Operation'을 적용
HTTP에서 제공하는 Method를 사용하여 API 호출을 합니다.
💡CRUD Operation이란?
- Create : 데이터 생성(POST)
- Read : 데이터 조회(GET)
- Update : 데이터 수정(PUT, PATCH)
- Delete : 데이터 삭제(DELETE)
HTTP Method를 사용하여, 데이터를 주고 받는 과정에서 명시적으로 어떤 요청을 보내는 것인지 알 수 있습니다.
//간단 예시
GET /movies/1REST API 구성요소 정리…
1. 자원(Resource) : HTTP URI
- 모든 자원에 고유한 ID가 존재하고, 이 자원은 Server에 존재 한다.
- 자원을 구별하는 ID는 ‘/groups/:group_id’와 같은 HTTP URI
Client는 URI를 이용해서 자원을 지정하고 해당 자원의 상태(정보)에 대한 조작을 Server에 요청한다.
2. 행위(Verb): HTTP Method
HTTP 프로토콜의 Method를 사용합니다.
HTTP 프로토콜은 GET, POST, PUT, PATCH, DELETE 와 같은 메서드를 제공하는데, 이를 통하여 명시적으로 데이터를 요청하는 행위를 표현할 수 있습니다.
3. 표현(Representation of Resource)
Client가 자원의 상태(정보)에 대한 조작을 요청하면 Server는 이에 적절한 응답(Representation)을 보냅니다.
REST에서 하나의 자원은 JSON, XML, TEXT, RSS 등 여러 형태의 응답을 받을 수 있다.JSON 혹은 XML를 통해 데이터를 주고 받는 것이 일반적입니다.
REST 디자인 원칙
1️⃣ 균일한 인터페이스
- 요청이 어디에서 오는지와 무관하게, 동일한 리소스에 대한 모든 API 요청은 동일하게 보여야 합니다.
2️⃣ 클라이언트-서버 디커플링.
- REST API 디자인에서 클라이언트와 서버 애플리케이션은 서로 간에 완전히 독립적이어야 합니다. 클라이언트 애플리케이션이 알아야 하는 유일한 정보는 요청된 리소스의 URI이며, 이는 다른 방법으로 서버 애플리케이션과 상호작용할 수 없습니다.
3️⃣ Stateless
- REST API는 stateless입니다. 이는 각 요청에서 이의 처리에 필요한 모든 정보를 포함해야 함을 의미합니다. 즉, REST API는 서버측 세션을 필요로 하지 않습니다. 서버 애플리케이션은 클라이언트 요청과 관련된 데이터를 저장할 수 없습니다.
4️⃣ 캐싱 가능성
- 가능하면 리소스를 클라이언트 또는 서버측에서 캐싱할 수 있어야 합니다. 또한 서버 응답에는 전달된 리소스에 대해 캐싱이 허용되는지 여부에 대한 정보도 포함되어야 합니다. 이의 목적은 서버측의 확장성 증가와 함께 클라이언트측의 성능 향상을 동시에 얻는 것입니다.
5️⃣ 계층 구조 아키텍처
- REST API에서는 호출과 응답이 서로 다른 계층을 통과합니다. 경험에 따르면 클라이언트와 서버 애플리케이션이 서로 간에 직접 연결된다고 가정하지 않는 것이 좋습니다. REST API는 엔드 애플리케이션 또는 중개자와 통신하는지 여부를 클라이언트나 서버가 알 수 없도록 설계되어야 합니다.
6️⃣ 코드 온디맨드(옵션)
- REST API는 일반적으로 정적 리소스를 전송하지만, 특정한 경우에는 응답에 실행 코드(예: Java 애플릿)를 포함할 수도 있습니다. 이 경우에 코드는 요청 시에만 실행되어야 합니다.
REST API의 장단점
장점
- 대규모의 고성능 통신을 안정적으로 지원
- 쉽게 구현하고 수정할 수 있다.
- 여러 플랫폼에서 사용할 수 있다.
- REST API 메시지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악할 수 있다.
단점
- HTTP Method 형태가 제한적이다.
- 요청해야할 리소스를 일일이 HTTP method와 URI를 통해 만들어줘야 합니다.
참조
