API를 많이 사용해봤지만 정확한 의미가 뭘까?
API(Application Programing Interface)는 지금 강의에서 몇 번 접한 적이 있다. 아니 꽤 다수라고 생각이 된다. 그 중 API하면 떠오르는 강한 이미지가 Naver 개발자 센터나 공공데이터에서 받아와서 JSON, XML로 파싱하던 데이터들이다. 그런데 현재 JSP를 배우고 Spring을 배우면서 RESTful API에 대한 설명을 들어보니 본래 알던 게 다가 아니라는 생각이 들었다. 대체 API가 정확히 뭘까?
다른 소프트웨어 시스템과 통신하기 위해 따라야 하는 규칙이다. API는 데이터베이스가 아니지만 액세스 권한이 있는 앱의 권한 규정과 '서비스 요청'에 따라 데이터나 서비스 기능을 제공하는 메신저 역할을 한다.
API는 실제 눈에 보이는 UI가 아니라서 그저 말로 이렇게 들어도 어떤 것인지 잘 상상이 안되기때문에 TV 리모콘, 점원 등 실제 눈에 보이는 중간 단계를 예를 들어 설명하곤 한다.
이 API에 대해서 더 자세히 풀이하면 너무나 길기때문에 다른 포스팅에서 작성하여 따로 링크를 걸 생각이다.
REST
REST(Representational State Transfer)는 웹의 장점을 최대한 활용할 수 있는 아키텍처로써 자원을 이름으로 구분하여 해당 자원의 상태를 주고받는 모든 것을 의미한다. REST 기반 아키텍처를 사용하여 대규모의 고성능 통신을 안정적으로 지원할 수 있고 쉽게 구현하고 수정할 수 있어 모든 API 시스템을 파악하고 여러 플랫폼에서 사용할 수 있다는 것이 장점이다.
REST API는 클라이언트가 HTTP URI를 통해 자원 정보에 대해 조작을 요청하고 HTTP Method를 통해 수행할 동작을 명시하면 서버에서 그에 적절한 형태(JSON, XML, TEXT, RSS)로 응답을 보내는 것으로 이루어져있다. 그래서 REST의 구성을 URI(자원-Resources), HTTP Method(행위-Verb), 표현(Representations) 세 가지로 이야기하기도 한다.
REST의 특징
이것은 스타일로도 불리며 제약조건이라고 할 수 있다. 아래에 기술된 6가지의 제약조건을 다 지켜야만 REST로 불릴 수 있으며 그 중 Uniform Interface(인터페이스 일관성)을 지키는 것이 어렵기에 그렇지 않은 경우 Web API 혹은 HTTP API로 부를 수 있다.
Stateless (무상태성)
HTTP Protocol을 기반으로 만들어 졌기에 Stateless의 성질을 가진다. 세션 정보나 쿠키 정보와 같은 상태 정보를 따로 저장하지 않고 API 서버에 들어오는 요청만 단순 처리하여 서비스의 자유도가 높아지고 구현이 단순하다. 중요한 것은 각각의 요청을 별개의 것으로 인식하며 이전 요청이 다음 요청 처리에 연관 되어서는 안된다.
Cacheable (캐시 가능)
위에서 기술한 것처럼 HTTP Protocol을 사용하기 때문에 웹에서 사용하는 기존의 인프라를 그대로 활용할 수 있다. 그 중 캐싱 기능 적용이 주제인데 HTTP프로토콜 표준에서 사용하는 Last-Modified 태그나 E-Tag를 이용하면 캐싱 구현이 가능하다. 이를 통해 응답이 빨라지고 REST Server 트랜잭션이 발생하지 않아 전체 응답시간, 성능, 서버의 자원 이용률을 향상 시킬 수 있다.
Client - Server 구조
Server는 자원(API data)를 제공하고 Client는 사용자 인증이나 context(세션, 로그인 정보) 등을 직접 관리하여 각각의 역할이 구분되어 있어 개발할 내용이 명확하고 서로 간에 의존성이 줄어든다.
Layered System(계층화)
REST server는 다중 계층으로 구성될 수 있고 보안, 로드밸런싱, 암호화, 사용자 인증 등을 추고하여 구조 상의 유연성을 줄 수 있다. 로드밸런싱, 공유 캐시 등을 사용하면 확장성과 보안성을 향상시킬 수 있다. 이러한 계층은 클라이언트에 보이지 않는 상태로 유지된다.
code-on-demand(optional)
REST 아키텍처는 소프트웨어 프로그래밍 코드를 클라이언트에 전송하여 클라이언트 기능을 일시적으로 확장하거나 사용자 지정할 수 있다. 하지만 서버에서 제공되는 코드를 실행해야 하기 때문에 보안 문제를 야기할 수 있다.
Uniform Interface(인터페이스 일관성)
서버가 표준 형식으로 정보를 전송하는 것을 말하며 모든 RESTful 웹 서비스 디자인의 기본이다. 서버는 데이터를 텍스트로 저장하되 HTML 표현 형식으로 전송할 수 있다.
여기에는 4가지 아키텍처 제약 조건이 있다.
(1) 리소스가 URI로 식별되야 한다.
(2) 클라이언트가 Resource를 생성, 수정, 삭제를 원하는 경우 Resource를 직접 주고 받는 것이 아닌 그 상태나 정보를 설명하는 데이터를 전송하여 Representation(표현)을 주고 받는다. 동일한 Resource에 대해 다른 Representation(표현)을 가질 수 있다.
(3) Client-Server 간 메시지에 자신에 대한 State나 정보 등을 충분히 설명할 필요가 있다. 그 Resonpse를 이해할 수 있도록 충분한 정보들을 HTTP Method, HTTP Status Code, HTTP Header등을 활용하여 주고받아야 한다. 그러나 Server가 제공하는 REST API는 그 스스로가 무엇을 하는 것인지 별다른 문서없이 충분히 설명되어져야 한다. - Self-descriptive message
(4) HASTOEAS (Hypermedia As The Engine Of Application State)
하이퍼미디어의 특징을 이용하여 HTTP Response에 다음 Action이나 관계되는 리소스에 대한 HTTP Link를 함께 리턴하는 것이다. 즉 웹 페이지 자체와 연관된 리소스에 대한 디테일한 링크를 표시 하는 등의 것이다.
RESTful API 인증이 두 번이나 나왔었는데요!
요즘 대부분의 서비스 시스템은 API를 기반하여 통신하기때문에 보안이 뚫리면 개인 정보 탈취를 비롯한 큰 문제가 생긴다. 이를 방지하기 위해서 RESTful 웹 서비스는 일반적인 로그인과 같이 API 서비스를 사용하고자 하는 대상자가 서비스 사용이 가능한지 여부를 확인하는 작업이 필요하다. AWS 사이트에서는 4가지의 일반적인 인증 방법을 설명하고있다.
HTTP 인증
(1) 기본 인증 : 가장 기본적이고 단순한 형태의 인증 방식으로 사용자 ID와 PASSWD를 HTTP Header에 Base64 인코딩 형태로 넣어서 인증을 요청한다.
(2) 전달자 인증 : 전달자 토큰은 서버가 로그인 요청에 대한 응답으로 생성하는 암호화된 문자열이다. 클라이언트는 리소스에 액세스하기 위해 요청 헤더에 토큰을 넣어 전송한다.
API 키
가장 기초적인 방법으로 특정 사용자만 알 수 있는 일종의 문자열이다. 개발자는 API 제공사의 포탈 페이지에서 API키를 발급받고 호출할 때 메시지 안에 넣어서 호출하면 서버가 메시지 속의 API키를 읽어서 누가 호출한 것인지 인증하는 흐름을 가진다.
모든 클라이언트가 같은 API 키를 공유하여 한 번 노출되면 전체 API가 뚫려버리는 문제가 있기때문에 높은 보안 인증이 필요한 때에는 권장하지 않는다.
OAuth
모든 시스템에 대해 매우 안전한 로그인 액세스를 보장하기 위해 암호와 토큰을 결합한 형태로 3자 인증방식이라고 할 수 있으며 페이스북이나 트위터와 같은 API 서비스 제공자들이 파트너 어플리케이션에 적용하는 방법이다.
예를 들어서 페이스북의 파트너 어플리케이션에서 페이스북 로그인을 수행할 때 클라이언트가 직접적으로 아이디와 패스워드를 입력해 전송하고 사용자 전용 페이지를 받아오는 것으로 보이지만 실제로는
(1) 파트너 어플리케이션에서 Client-Id, Client-Secret 등의 정보와 페이스북 정보 접근 권한을 Scope라는 필드를 통해 요청
(2) 브라우저는 페이스북 로그인 페이지로 이동하여 로그인을 요청
(3) 페이스북에서 클라이언트에게 로그인 창을 보내 클라이언트가 ID/PASSWORD 입력
(4) 페이스북이 사용자를 인증해 관련 정보를 브라우저로 전달해 로그인 완료 페이지로 Redirection을 요청
(5) 파트너 어플리케이션은 받은 정보를 가지고 페이스북에 인증 받은 사용자인지 확인을 요구
(6) 페이스북은 다시 해당 정보를 보고 클라이언트가 인증된 사용자임을 확인해주고 API Access Token을 발급
(7) 파트너 어플리케이션에서 전달 받은 API Access Token으로 API 서비스에 접근시킨다
파트너 어플리케이션에 페이스북의 ID, PASSWORD 정보를 직접 전달하지 않고 페이스북이 대신 인증해 제공하는 Token을 교환하므로 안전성이 보장된다고 할 수 있다.
그렇다면 RESTful이 어려운 이유가 뭘까?
위에 기술된 제약조건 중 Uniform Interface(인터페이스 일관성) 때문에 RESTful이다 아니다의 논쟁이 큰 것 같다.
서버에게 해야할 요청을 상세 기술하면 매개변수들 중에 데이터와 명령이 혼재되는 문제가 발생하고 요청이 눈에 보인다는 것은 보안 이슈가 있을 가능성을 말하기 때문에 REST를 파괴하는 한이 있더라도 유연하게 구성할 필요가 있기 때문이다.
이렇게 모든 상황에서 완벽히 지킬 수 없기 때문에서 내가 만든 것은 REST다, 당신이 만든것은 REST라고 할 수 없다는 다툼이 있는 것 같다.
참조 Blog, Web
https://www.hanl.tech/blog/api%EB%9E%80-api%EC%9D%98-%EC%A0%95%EC%9D%98%EC%99%80-%EC%A2%85%EB%A5%98-%EC%9E%A5%EB%8B%A8%EC%A0%90/ (API)
https://ittrue.tistory.com/31 (API)
https://aws.amazon.com/ko/what-is/restful-api/ (AWS에서 말하는 API)
https://meetup.toast.com/posts/92 (REST API)
https://hanamon.kr/rest-api/ (REST API)
https://aws.amazon.com/ko/what-is/restful-api/ (REST 정의)
https://m.boostcourse.org/web316/lecture/16740 (REST 제약조건)
https://midnightcow.tistory.com/entry/REST-What-is-REST-2 (Uniform Interface 제약조건)
https://bcho.tistory.com/955 (API 보안 정보)
