REST API

API

API는 Application Programming Interface의 약자로 응용 프로그램에서 사용할수 있도록, 운영체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만드는 인터페이스를 뜻한다.주로 파일 제어, 창 제어, 화상 처리, 문자 제어 등 자신이 원하는 기능을 제어할 수 있도록 하는 인터페이스를 제공한다. 따라서 원하는 기능을 제어하는 API를 직접 만들 수도 있다.​

Web API

웹 서버 또는 웹 브라우저를 위한 애플리케이션 프로그래밍 인터페이스이다. HTTP 서비스이고 다양한 클라이언트에서 접근이 가능하도록 설계되어있다. Web 환경을 통해 제공되는 데이터 CRUD 인터페이스를 제공한다.HTTP 표준 접근 방식을 이용하며 플랫폼 환경, 클라이언트 환경의 제한이 없는 서비스 구현이 가능하다.

REST

REST는 Representational State Transfer의 약자이다. 자원을 URI로 표시하고 해당 자원의 상태를 주고 받는 것을 의미한다. REST는 프로토콜이나 표준이 아닌 아키텍처 원칙 세트이며 API 개발자는 REST를 다양한 방식으로 구현할 수 있다.

REST의 구성요소

자원(Resource): URI

• 모든 자원에 고유한 ID가 존재하고, 이 자원은 Server에 존재한다.

• 자원을 구별하는 ID는 /orders/order_id/1 와 같은 HTTP URI 이다.

행위(Verb): HTTP Method

• HTTP 프로토콜의 Method를 사용한다.

• HTTP 프로토콜은 GET, POST, PUT, DELETE와 같은 메서드를 제공한다.

표현(Representations) : HTTP Message Payload

• Client가 자원의 상태 (정보)에 대한 조작을 요청하면 Server는 이에 적절한 응답 (Representation)을 보낸다.

• REST에서 하나의 자원은 JSON, XML, TEXT, RSS 등 여러 형태의 Representation으로 나타낼 수 있다. (현재는 JSON으로 주고 받는 것이 대부분이다.)

따라서, REST는 URI를 통해 자원을 표시하고 HTTP METHOD를 이용하여 해당 자원의 행위를 정해주며 그 결과를 받는 것을 말한다.

REST의 CRUD 메서드

Method	CRUD	SQL	설명
POST	Create	INSERT	생성
GET	Read	SELECT	읽기
PUT	Update	UPDATE	갱신
DELETE	Delete	DELETE	삭제

​

RESTful

REST를 REST답게 쓰기 위한 방법으로 공식적이지 않은 개발자들이 비공식적으로 제시한 것이다. 이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것이 목적.HTTP와 URI 기반으로 자원에 접근할 수 있도록 제공하는 애플리케이션 개발 인터페이스이다. 기본적으로 개발자는 HTTP 메소드와 URI 만으로 인터넷에 자료를 CRUD 할 수 있다.

• CRUD의 기능을 전부 활용해야한다. (예. POST로만 모든 것을 처리하면 RESTful이 아니다.)

• URI에 resource과 id외 정보만 들어가야한다. (예. "/students/updateName"은 RESTful이 아니다.)

자세한 설명은 아래 사이트 참고

REST API(RESTful API, 레스트풀 API)란 - 서버, 구현, 사용법

URL vs URI

[URL]

• 프로토콜: http, https, ftp 등

• 호스트네임: 도메인 or IP (서버컴퓨터의 이름 - 위치)

• URL path: 서버컴퓨터(host)에서 클라이언트가 요청한 파일 디렉토리

• 쿼리: 추가적 질문사항

[URI]

• Identifier: 식별자, 자원 식별자, id값(index)

• URI가 URL을 포함

• 예시: http://localhost/article/7 -> article(예를 들어 db 테이블 이름)이라는 db에 저장된 데이터 7번째 것을 나타냄

즉, URL은 서버컴퓨터에서 클라이언트가 요청한 파일의 디렉토리를 나타내지만 URI는 자원의 고유 식별자(id값)이다.​

Authorize

전통적인 인증 시스템

1. 1.유저가 ID/PW 를 입력한다. (POST /authenticate username=***&password=***)

2. 2.서버는 request 가 들어오면 연동된 계정 DB를 쿼리하여 유저를 검증하고, 유효한 유저라면 세션을 생성하고 세션 정보를 response 헤더에 포함시켜 반환한다.

3. 3.클라이언트는 제한된 end points 에 접근할 때 모든 request header 에 반환받은 세션 정보를 포함시킨다.

4. 4.만약 세션 정보가 유효하면, 서버는 유저가 특정 end point 에 접근하는 것을 허용하고 렌더링된 HTML 내용을 반환한다.

이러한 전통적인 인증 시스템은 문제가 없었다. 웹 어플리케이션은 잘 동작하고, 사용자 인증을 거쳐 특정 end point 로의 접근을 제한할 수 있다. 하지만 전통적인 인증 방식으로 동작하는 어플리케이션을 모바일 클라이언트(안드로이드 등)에서 동일하게 사용할 수 없다는 문제가 있다. 이유는 아래와 같다.

• 세션과 쿠키는 모바일 어플리케이션에서 make sense 하지 않다. 서버에서 생성된 세션과 쿠키를 모바일 클라이언트에서는 공유할 수 없다.

• 현재 어플리케이션에서 렌더링된 HTML 이 반환 되었으나, 모바일 클라이언트에서는 JSON 또는 XML 과 같은 포맷의 응답이 필요하다.

즉 이러한 경우, 클라이언트 독립적인 어플리케이션이 필요하다. (클라이언트의 종류에 따라 어플리케이션을 개발하는 것이 아니라, 클라이언트의 종류에 상관없이 동일한 동작을 할 수 있는 어플리케이션이 필요하다는 의미이다. )​

토큰 기반 인증 시스템

토큰 기반 인증에서는 쿠키와 세션이 사용되지 않는다. 토큰은 서버로의 모든 request 에 대해 유저를 인증하기 위해 사용된다. 전통적인 인증 시스템에서의 인증 시나리오를 토큰 기반 인증 시스템으로 재설계하면 아래와 같다.

1. 1.유저가 ID/PW 를 입력한다 (POST /authentication username=***&password=***)

2. 2.서버는 request 가 들어오면 연동된 계정 DB를 쿼리하여 유저를 검증하고, 유효한 유저라면 토큰을 생성하고 토큰 정보를 response 헤더에 포함시켜 반환한다. 이로 인해, 유저는 local storage 에 토큰을 저장할 수 있다.

3. 3.클라이언트는 제한된 end points 에 접근할 때 모든 request header 에 반환받은 토큰 정보를 포함 시킨다.

4. 4.만약 토큰 정보가 유효하면, 서버는 유저가 특정 end point 에 접근하는 것을 허용하고 json 또한 xml 포맷으로 응답한다.

토큰 기반 인증 시스템의 예제 스키마는 다음과 같다.

1. 1.웹 어플리케이션이나 모바일 클라이언트 등에서 API 에 대한 request 가 생성된다.

2. 2.request 는 서비스로 전달 되고, 많은 request 가 생성되면 다수 서버가 필요하다.

3. 3.다수 서버 중 가장 적합한 서버로 request 를 전달하기 위해 LB(Load Balencer)가 사용된다. request 가 발생하면, LB 가 request 를 제어하고 특정 서버(가장 적합한)로 request 를 redirect 시킨다.

4. 4.하나의 어플리케이션은 여러 서버로 배치된다. request 가 생성될 때마다 백엔드 어플리케이션은 request header 를 가로채서 authentication header 내의 토큰 정보를 추출해내고, DB 쿼리는 해당 토큰을 사용하여 수행된다. 만약 토큰이 유효하고 end point 접근 권한을 가지고 있다면 서비스가 제공되고, 그렇지 않다면 403 response (forbidden status) 를 반환한다.

​

ETC

HTTP Response Code

2xx 성공

• 200: 클라이언트의 요청을 정상적으로 수행함.

• 201: 클라이언트에게 생성 작업을 요청 받았고, 생성 작업을 성공함.

• 204: 요청은 성공 했지만 응답할 콘텐츠가 없음.

3xx 리다이렉션

• 301: 클라이언트가 요청한 리소스에 대한 URI가 영구적으로 변경되었을 때 사용함.

• 302: 301과 같으나 임시적으로 주소가 바뀌었을 경우 사용함.

• 304: 이전에 방문했을 때의 요청 결과와 다르지 않을 경우 사용함. 캐시된 페이지를 그대로 사용.

• 307: 임시 페이지로 리다이렉트.

4xx 클라이언트 오류

• 400: 클라이언트가 올바르지 못한 요청을 보냄.

• 401: 로그인을 하지 않아 페이지를 열 권한이 없음.

• 403: 금지된 페이지, 로그인을 하든 안하든 접근할 수 없음. (관리자 페이지)

• 404: 찾을 수 없는 페이지, 주소를 잘 못 입력했을 때 사용함.

• 403 대신에 사용할 수도 있음.(해커들의 공격을 방지하고자 페이지가 없는 것처럼 위장함)

• 408: 요청 시간이 초과됨.

• 409: 서버가 요청을 처리하는 과정에서 충돌이 발생한 경우. (회원가입 중 중복된 아이디인 경우)

• 410: 영구적으로 사용할 수 없는 페이지.

5xx 서버 오류

• 501: 해당 요청을 처리하는 기능이 만들어지지 않음.

• 502: 서버로 가능 요청이 중간에서 유실된 경우.

• 503: 서버가 터졌거나 유지 보수 중 (유지 보수 중일때는 유지 보수중이라는 것을 알려주는 페이지로 전송해주는 것이 좋음)

• 504: 서버 게이트웨이에 문제가 생겨 시간 초과가 된 경우.

• 505: HTTP 버전이 달라 요청이 처리할 수 없음.

​​