API와 Authentication에 대해 알아보자. 기존에 정리해놓은 글들이 있어서, 참고하면서 작성했다.
API(Application Programming Interface)
: 직역하자면 어플리케이션 프로그래밍을 위해 제공되어지는 정보묶음이라고 생각하면될 것 같다. 소프트웨어 프로그램과 컴퓨터를 이어주는 역할을 하며, 사용자와 컴퓨터를 이어주는 유저 인터페이스와 같이 개발자들을 위해서 소프트웨어 프로그램과 컴퓨터를 이어주는 인터페이스이다.
RESTful API
: REST는 REpresentational State Transfer의 약자이다. 이 REST가 나타난 계기는 기존 체제의 WEB을 건드리지 않고 지속적인 발전시키기 위함에 있었다. WEB은 1991년에 등장하여 HTML(표현형식), URI(식별자), HTTP(전송방법)을 가지고 있었다. 이 중, Protocol을 수정하면서 웹 호환성을 무너뜨리지 않을 수 있을까? 라는 생각에서 Roy Fielding이 작성한 박사논문에서 처음으로 REST가 소개되었다. (박사논문으로… 천재는 많다..)
이후, 나타난 SOAP 방식과 REST 방식은 API에서 많이 사용되었다. 상황에 따라, 두가지 방식을 모두 제공하는 FLICKER API와 같은 API도 있었다. 하지만, SOAP 방법은 아래의 사진만 봐도 알겠지만 REST 방식에 비해서 매우 복잡하다.
REST는 실제로 Roy Fielding이 의도한대로 WEB 호환성을 무너뜨리지않고 발전을 시킬 수 있었다. 단, ‘엄청나게 오랜시간이 걸렸다’, ‘설정하는 과정에서 사용된 오타 또한 호환성을 유지하기위해 앞으로 계속 그대로 사용행한다.’ 등의 단점을 가지고 있다. 물론, WEB에서는 잘 활용된다.
REST API조건
: REST 하기 위한 조건은 Client server, Stateless, Cache, Uniform Interface, Layered System, Code-on-demand 이다. 이 중, Uniform Interface에 대한 제약을 잘 지키지 못한다. API를 REST 하게 만드는 건 왜 어려울까? 이는 HTML를 사용하는 WEB과는 다르게 API는 JSON을 사용하기 때문이다.
Uniform Interface는 identification of resources, manipulation of resources through representation, self-descriptive messages, hypermedia as the engine of application state(HATEOS)를 만족해야한다 현재, 대부분 우리가 알고있는 REST한 API는 identification of resources, manipulation of resources through representation까지는 만족한다. 하지만, self-descriptive messages, hypermedia as the engine of application state(HATEOS)는 만족하지 않는다. self-descriptive messages의 경우, JSON을 통해서 들어가는 요청의 목적지가 빠져있다. Content-type header이 명확히 작성되어 parsing이 가능하게 해아한다. HATEOS의 경우, JSON이기에 링크 명세가 불가능하다.
위의 문제를 해결하기위해서는 본인이 직접 만든 명세를 IANA에 등록 혹은 헤더에 link로 profile에 대한 정보를 제공하는 방법이 있다.
Authentication
: 클라이언트가 자신이라고 주장하는 유저가 자신이 맞는지 확인하는 과정을 의미한다. 서비스를 누가 사용하며, 추적이 가능하도록 하며, 타인에게 사용자의 정보를 보호하기 위해서 필요하다. 유저에게 권한을 허락하는 Authorization과 혼동하지 말자.
이미지 출처:https://velog.io/@sdc337dc/%EC%9B%B9-%EC%9D%B8%EC%A6%9DAuthentication-%EC%9D%B8%EA%B0%80Authorization
유저의 목표는 리소스에 접근하여 리소스를 활용하는 것이다. 여기서 리소스는 이미지, 텍스트, 동영상 등이 될 수 있다. 그렇다면 한 유저에게 그 유저만 접근 할 수 있는 특정 리소스는 어떻게 줄 수 있을까? 이 때, Authentication이 활용되는 것이다.
우리가 가장 많이 쓰는 Web에서는 Authentication이 어떻게 쓰일까? Web은 통신을 위해서 HTTP를 사용하는데, HTTP의 특징인 Stateless를 고려하여 Cookie, Session, JWT 방식이 존재한다.
Cookie
: 쿠키는 클라이언트(컴퓨터)에 저장되는 텍스트 형식의 데이터를 의미한다. 쿠키는 방문한 사이트에서 저장되는 파일로, 인터넷 사용정보를 저장한다. 유효시간을 명시할 수 있으며, 유효시간이 정해지면 브라우저가 꺼져도 인증이 유지된다. 예를 들어, 우리가 웹사이트에 로그인한 아이디 및 비밀번호를 저장하여 편하게 로그인할때 쿠키가 사용된다.
Session
: 세션은 쿠키를 기반으로한다. 세션은 쿠키와 다르게 데이터를 서버측에서 관리한다. 따라서, 세션은 브라우저를 끄기전까지 인증정보를 유지한다. 쿠키보다 보안성은 좋지만, 서버가 커지게되면 세션에 너무 많은 양의 정보를 저장해야되기때문에 성능저하의 원인이 된다.
JWT
: JSON Web Token을 의미한다. 로그인을 통해서 예시를 들어보자. 유저가 아이디와 비밀번호를 입력하여 로그인을 한다. Server에서 seceret key를 이용하여 JWT 토큰을 생성해 Browser로 전송한다. 이후, 인증이 필요한 활동을 할 때(ex. 마이페이지), JWT 토큰을 요청과 함께 전송한다.
