API란?
API는 응용 프로그램에서 사용할 수 있도록, 운영 체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스를 뜻한다. 주로 파일 제어, 창 제어, 화상 처리, 문자 제어 등을 위한 인터페이스를 제공한다.
-위키백과 설명-
API는 Application Programming Interface의 줄임말로써 응용프로그램 인터페이스를 뜻한다. [인터페이스가 무엇인지 먼저 설명하자면 인터페이스는 서로 다른 두 사람,사물,시스템 간의 원할한 소통이 가능하도록 해주는 시스템을 뜻한다. 가장 흔히 알려진 UI는 User Interface는 사람과 사물 간의 소통을 해주는 매개체(시스템)을 뜻하고 이에 대한 예시로는 터치스크린이나 마우스가 있다.] API는 User 대신 Application Programming이 들어 갔다. 이는 즉, 사람과 사물이 아닌 응용프로그램들 간의 의사소통을 가능하게 해주는 모든 시스템을 뜻한다. 또는 간결하게는 프로그램들이 서로 소통하는 방법이라고도 할 수 있다.
API의 동작원리
API의 동작원리를 보면 A프로그램이 요청을 하면 API는 이 요청을 B프로그램한테 전달 해주는 것을 알 수 있다. B프로그램이 요청에 대한 응답을 하면 API가 이를 받아서 A프로그램한테 응답을 전달해준다.
API가 필요한 이유는??
위에서 API는 응용프로그램들 간의 의사소통을 가능하게 해주는 시스템 또는 방법이라고 정의 했는데, 이는 바꿔말하면 API가 있으면 응용프로그램을 사용할 수 있다는 소리다. 이를 좀 풀어서 말하자면, API의 정해진 사용 방법 대로만 행동한다면 얼마든지 다른 프로그램들에서 제공하는 기능들을 내가 원할 때 원하는 기능만 골라서 사용할 수 있다는 것이다.
이게 왜 장점이라고 할 수 있냐면, 예를 들어, 내가 만드는 사이트에 로그인을 하기 위해서는 회원가입이 필수 일 것이다, 하지만 사실 요즘 회원가입을 하는 과정 자체를 귀찮아 하는 사람이 많아 이를 대신하여 사이트를 카카오,구글,네이버,페이스북 아이디 등으로 대체 할 수 있게 해주는 사이트들을 많이 보았을 것이다. 이 때 이렇게 특정 기업의 아이디로 로그인하게 해주는 기능이 API이다. 이를 사용한다면 우리는 회원가입에 있어서 많은 시간 절약을 할 수 있을 것이고, API를 제공하는 측에서는 영향력을 넓힐 수 있어 윈윈하는 것과 마찬가지다. 또다른 API의 장점을 보자면 API를 통해 안전한 데이터 제공이 가능해져 많은 기업이나 공공기관에서 데이터베이스를 공유하여 우리가 활용 할 수 있게 해주기 때문이다.
사실 내가 이번 문서를 작성하게 된 것은 바로 이 Rest api 때문이다!!
나와 같이 잘못 생각한 사람이 있을지는 모르겠지만 나는 Rest api를 django 프로젝트에 적용하려고 했는데 사실 rest api를 만들라는 것을 get post put delete로 코드를 다시 구성하라는 뜻인줄 알았다. 이는 얼마나 내가 기본 지식에 대해 잘 못 알고 이로 인해 며칠을 그냥 날려버렸기 때문에 나와 같은 사람이 없었으면 하는 점에서 작성한다.
가장 먼저 결과 부터 말하자면, REST API를 만들라는 것은 우리가 구현한 API를 RESTful 하게 만들어서 클라이언트나 다른 개발자가 봤을때 아무 문제 없이 이해하고 사용할 수 있게 만들라는 뜻이다. 그럼 어떻게 REST하게 만드나 하면 먼저 수단으로는 REST API용 프레임워크를 사용해서 저장하거나 문서화 시키면 된다. REST하게가 무엇이냐는 밑에서 부터 설명하겟다.
REST하다는 것은?
REST(REpresentational State Transfer):대표적인 상태 전달 이라는 뜻으로 대표성을 갖는 제일 많이 쓰이는 상태로 전달하는 방식을 뜻하는 것 같다. 사전적 의미로는 "웹에 존재하는 모든 자원(이미지,동영상,DB자원)에 고유한 URI를 부여해 활용"한다고 뜻한다. 이를 보면 잘 이해가 되지 않는다.
REST의 구성
-HTTP Method, URI, 표현
REST의 특징
1)Uniform Interface: HTTP 표준에만 따른다면 , 특정 언어나 기술에 종속되지 않고 모든 플랫폼에 사용이 가능하며, URI로 지정한 리소스에 대한 조작이 간으한 아키텍처 스타일을 의미한다.
2)Stateless(무상태성):상태성을 갖지 않는다는 소리로서 저장소에 상태정보를 따로 저장하고 관리하는 것이 아닌, API 서버에 들어오는 요청만을 단순 처리하는 것을 말한다.
3)Cacheable(캐시가능):HTTP가 가진 가장 강력한 특징 중의 하나인 캐싱 기능을 적용할 수 있다.
4)Self-descriptiveness:동사(Method)+명사(URI)로 이루어져있어 어떤 메서드에 무슨 행위를 하는지 쉽게 알 수 있다. 즉, REST API 메세지만 보고 기능을 이해할 수 있게 해줘야한다.
5)Client-Server구조: 서버와 클라이언트의 역할을 확실히 나누어주어서 서로간의 의존성이 줄어들게 하는 것이다.
6)계층형 구조: 계층 구조로서 API에 새로운 기능을 추가할 때 아무 문제가 없다.
RMM을 통한 REST 이해
REST 요소를 파악하는데는 Richardson Maturity Model(RMM)을 기준으로 이해하는 것이 좋은 것 같다.
레벨0
웹의 기본 메커니즘을 전혀 사용하지 않는 단계로, HTTP를 통해 데이터를 주고받지만 모든 데이터 요청 및 응답과 관련한 정보를 HTTP의 body 정보를 활용한다.
POST /appointmentService HTTP/1.1
[various other headers]
<openSlotRequest date = "2010-01-04" doctor = "mjones"/>
POX(Plain Old XML)로 요청과 응답을 주고받는 RPC 스타일 시스템이다. 이 때 HTTP method는 POST만 사용하며, 특정 서비스를 위해 클라이언트에서 접근할 endpoint는 하나이다.
레벨 1 - 리소스
RMM에서 REST를 위한 첫 단계는 리소스를 도입하는 것이다. 그래서 이제는 모든 요청을 단일 서비스 endpoint로 보내는 것이 아니라, 개별 리소스와 통신한다.
POST /doctors/mjones HTTP/1.1
[various other headers]
<openSlotRequest date = "2010-01-04"/>
즉, 함수를 호출하고 인자들을 넘기는 것이 아니라 다른 정보를 위해 인자들을 제공하는 특정 리소스로 요청을 보낸다. 이럴 경우의 이점은 자원이 외부에 보여지는 방식과 내부에 저장되는 방식을 분리 할 수 있다는 것이다. 예를 들면 클라이언트 단에서 완전히 다른 포맷으로 저장하더라도 JSON 형태의 데이터를 요청할 수 있다.
레벨 2 - HTTP Method
레벨 1의 URL + HTTP Method 조합으로 리소스를 구분하는 것으로 응답 상태를 HTTP Status code 를 활용한다. 현재 가장 많은 Restful API가 이 단계를 제공한다.
GET /doctors/mjones/slots?date=20100104&status=open HTTP/1.1
Host: royalhope.nhs.uk
발생한 에러의 종류를 커뮤니케이션하기 위해 상태코드(status code)를 사용하는 것, 그리고 안전한 오퍼레이션(GET 등)과 안전하지 않은 오퍼레이션 간의 강한 분리를 제공하는 것이 레벨 2의 핵심 요소이다. 우선, Status Code를 사용한다는 것은 어떤 의미일까?기존에는 유저 생성 요청을 했을 경우 302 등의 리다이렉트 요청을 서버에서 내려주는 방식이었다면,지금은 201(created)로 유저 생성 성공을 알릴 뿐 페이지 이동은 Client 단에서 해결하는 방식이다.(login의 경우 성공은 200, 실패시 인증실패는 401, 성공했으나 권한 문제시엔 403 등)즉, 서버는 순수하게 api로서의 기능만을 제공하게 된다.(view는 Client에서..)
두번째로, 강한 분리를 제공하는 것이 어떤 이점이 있는 것일까?
HTTP에서 GET은 멱등방식으로 자원을 추출하는데, 이에 어떤 순서로든, 얼마든지 호출하든 매번 같은 결과를 얻도록 한다. 이에 통신상의 모든 참여자에게 '캐싱'기능을 지원하는 다양한 방법을 제공한다.
레벨 3 - 하이퍼미디어 컨트롤
HATEOAS(Hypertext As The Engine Of Application State) 애플리케이션 상태 엔진으로서의 하이퍼미디어 ㅡㅡ..
하이퍼미디어란 하나의 컨텐츠가 텍스트나 이미지, 사운드와 같은 다양한 포멧의 컨텐츠를 링크하는 개념이다. 이것은 관련 컨텐츠를 보기위해 링크를 따라가는 방식과 유사한 방식으로 동작하는데, 클라이언트가 다른 자원에 대한 링크를 통해 서버와 (잠재적으로 상태 변이를 초래하는) 상호작용을 한다.
즉, 특정 API를 요청한 후 다음 단계로 할 수 있는 작업을 알려주는 것이며, 다음 단계의 작업을 위한 리소스의 URI를 알려주는 것이다. 이 단계를 적용하면 클라이언트에 영향을 미치지 않으면서 서버를 변경하는 것이 가능하다.
GET /doctors/mjones/slots?date=20100104&status=open HTTP/1.1
Host: royalhope.nhs.ukHTTP/1.1 200 OK
[various headers]
<openSlotList>
<slot id = "1234" doctor = "mjones" start = "1400" end = "1450">
<link rel = "/linkrels/slot/book"
uri = "/slots/1234"/>
</slot>
<slot id = "5678" doctor = "mjones" start = "1600" end = "1650">
<link rel = "/linkrels/slot/book"
uri = "/slots/5678"/>
</slot>
</openSlotList>
단점은, 클라이언트가 수행할 작업을 찾기 위해 링크를 따라기기 때문에 컨트롤 탐색에 꽤 많은 호출이 발생할 수 있다는 것이다. 또한 복잡성이 증가할 수 있으며, HTTP 요청상에 나타나는 부하로 낮은 지연시간이 요구될 때 문제가 될 수 있다. HTTP 기반의 REST 페이로드는 JSON 또는 바이너리 등의 포맷을 지원하므로 실제로 SOAP 보다 훨씬 간결할 수 있지만 쓰리프트와 같은 바이너리 프로토콜에는 상대가 되지 못한다. 또한 웹소켓의 경우 HTTP 초기 핸드셰이크 후에 클라이언트와 서버 간에 TCP 접속이 이루어지고 브라우저에서 스트림 데이터를 보낼 때 효율적일 수 있다. 따라서 HTTP가 대규모 트래픽에는 적합할 수 있지만 TCP 또는 다른 네트워킹 기술 기반의 프토토콜과 비교하면 낮은 지연시간이 필요한 통신에는 그다지 좋은 선택이 아닐 수 있다.
이러한 단점에도 HTTP 기반의 REST는 서비스 대 서비스의 상호작용을 위해 합리적이고 기본적인 선택이다.
출처:RESTful API란 ? (tistory.com)
RESTful API란 ?
개발 공부를 시작하고 자주 접하고 그냥 지나친 개념 중에 하나이다. 면접 질문으로도 자주 나온다고 하고, 실제로 채용공고 필요 역량에도 REST 등 인터넷 기반 프로토콜/ 기술에 대한 이해를 요
brainbackdoor.tistory.com
위 내용을 내 나름대로 요약 해보겠다
먼저 저 3단계까지 다 완료되어야 우리가 흔히 말하는 RESTful한 API라고 부를 수 있는 것이다.
0단계:URL을 하나만 가지고 있어 모든 작업을 한페이지에서 실행해야 하면 Method도 POST 하나만 사용할 수 있다.
1단계:이제는 URL을 복수로 사용할 수 있어 요청을 개별 리소스와 통신할 수 있다. 하지만 여전히 Method는 POST 하나만 이용 할 수 있다.
2단계: 이제 URL + HTTP Method 조합으로 리소스를 구분할 수 있으며 이는 즉 GET POST PUT DELETE를 사용할 수 있다는 뜻이다. 동시에 응답 상태를 알려주는 HTTP Status code를 사용할 수 있다.
3단계:HATEOAS(Hypertext As The Engine Of Application State)를 이용한다. 즉 하이퍼링크를 통해 다음 단계로 할 수 있는 작업을 알려준다 또한 이 단계를 적용하면 클라이언트에 영향을 미치지 않으면서 서버를 변경하는 것이 가능하다.
내 생각
마지막으로 RESTful 한게 무엇이냐에 대한 나의 생각을 얘기하기전에 먼저 REST 자체는 독립적 진화를 가능하게 하기 위해 만들어 졌다고 했다. 즉, 서버에 변화가 생겨도 클라이언트들에게는 아무런 영향을 주지 않게 시스템을 구현하는 것을 뜻한다. 예를 들면 우리가 쓰는 웹 브라우저에 변화가 생겨도 우리는 그것을 전혀 인식하지도 못하고 또 쓰는데 아무런 불편함이 없는 것을 들 수 있다. 즉 우리가 무엇인가를 RESTful 하게 만든다는 것은 우리와 컨택하는 클라이언트가 바뀌어도 전혀 문제 없이 우리 시스템을 구성해놓으면 되는 것이다. 그렇게 하기 위해 명세서를 만들고 모두가 익숙한 HTTP의 메소드의 GET POST PUT DELETE를 사용하는거 같다. 완전히 RESTful하게 형식을 지키고 있는 것이 많지 않지만 우리는 이들을 모두 REST API라고 부른다 왜냐하면 서로 소통하는데 문제가 없기 때문이다.