API란?
Application Programming Interface(애플리케이션 프로그램 인터페이스)의 약자로, 소프트웨어 응용 프로그램에서 다른 소프트웨어 구성 요소 또는 서비스와 상호작용하기 위한 인터페이스를 제공하는 프로그래밍 기술이다.
즉, API는 응용 소프트웨어를 만드는데 쓰는 매개체나 통신규칙이다. 클라이언트와 서버 사이의 데이터 전송 통신을 위한 규칙이나 룰, 방법이라고도 이해할 수 있다.
예를 들어, 기상청의 소프트웨어 시스템에는 일일 기상 데이터가 들어 있다. 휴대폰의 날씨 앱은 API를 통해 이 시스템과 상호작용하여 휴대폰에 매일 최신 날씨 정보를 표시한다.
API를 사용하면 다른 소프트웨어 구성 요소와 상호작용하기 위해 필요한 복잡한 코드 작성을 줄일 수 있으며, 더욱 빠르고 효율적인 소프트웨어 개발을 가능하게 한다.
API의 종류
REST API
REST란
- HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고,
- HTTP Method(POST, GET, PUT, DELETE, PATCH 등)를 통해
- 해당 자원(URI)에 대한 CRUD Operation을 적용하는 것을 의미합니다.
CRUD Operation: 대부분의 컴퓨터 소프트웨어가 가지는 기본적인 데이터 처리 기능인 Create(생성), Read(읽기), Update(갱신), Delete(삭제)를 묶어서 일컫는 말
REST API란 이런 REST의 원리를 따르는 API를 의미합니다.
REST API 설계 예시(좋은/안 좋은 API 사례)
1. URI는 동사보다는 명사를, 대문자보다는 소문자를 사용하여야 한다.
Bad Example http://khj93.com/Running/
Good Example http://khj93.com/run/
2. 마지막에 슬래시(/)를 포함하지 않는다.
Bad Example http://khj93.com/test/
Good Example http://khj93.com/test
3. 언더바 대신 하이픈을 사용한다.
Bad Example http://khj93.com/test_blog
Good Example http://khj93.com/test-blog
4. 파일확장자는 URI에 포함하지 않는다.
Bad Example http://khj93.com/photo.jpg
Good Example http://khj93.com/photo
5. 행위를 포함하지 않는다.
Bad Example http://khj93.com/delete-post/1
Good Example http://khj93.com/post/1
RESTful API의 의미와 HTTP 규약 관계
RESTFUL이란 REST의 원리를 따르는 시스템을 의미한다. 하지만 REST를 사용했다 하여 모두가 RESTful 한 것은 아니다. REST API의 설계 규칙을 올바르게 지킨 시스템을 RESTful하다 말할 수 있으며, 모든 CRUD 기능을 POST로 처리하는 API 혹은 URI 규칙을 올바르게 지키지 않은 API와 같이 REST API의 설계 규칙을 올바르게 지키지 못한 시스템은 REST API를 사용했음에도 RESTful 하지 못한 시스템이라고 할 수 있다.
GraphQL
웹 클라이언트가 데이터를 서버로부터 효율적으로 가져오는 것이 목적인 쿼리 언어로 API를 위한 쿼리 언어라고 할 수 있다.
REST API와 비교
- URL 엔드포인트
REST API는 URL + METHOD 를 조합하기 때문에 다양한 엔드포인트가 존재하지만,
GraphQL은 엔드포인트가 하나만 존재한다. (/graphql) 하나의 엔드포인트를 가지고, 쿼리 조합을 통해 데이터를 요청한다.
ex. Book, Library에 대한 API를 설계할 때
REST API의 경우
/library/book
/library
/library/book/{id} 처럼 설계해야 하지만
GraphQL의 경우에는 /graphql 엔드포인트 요청에 따라 쿼리로 조합해서 요청하면 되기 때문에 API가 점점 늘어남에 따라 URL을 설계하고 만들어주지 않아도 된다. - response 데이터
REST API의 경우 return 되는 response 데이터가 정해져 있다. 그렇기 때문에 이전 API response에 다른 컬럼들이 추가되면 해당 파일을 계속 수정해줘야 하고, API별로 response가 다르면 그에 따른 DTO를 각각 다 만들어줘야 한다.
하지만, GraphQL은 쿼리로 요청하기 때문에 클라이언트가 원하는 데이터를 가져와서 사용할 수 있다.
gRPC
RPC는 Remote Procedure Call로 프로세스간 통신 기법 중 하나이다. 다른 프로세스에 있는 함수를 호출할때, 마치 같은 프로세스 내에 있는 것처럼 호출할 수 있다. 클라이언트는 일반 로컬 메소드를 호출하는 것처럼 사용하면 된다. RPC는 다양한 환경, 플랫폼에 제약없이 사용할 수 있어 분산 시스템 기법에 효과적이다.
gRPC는 구글에서 개발한 오픈 소스 RPC 프레임워크이다. 기본적인 개념은 RPC와 동일하지만 특징으로 HTTP/2 기반으로 양방향 스트리밍을 지원하고 HTTP/2를 사용함으로써 메세지의 압축률과 성능이 좋다는 점이 있다.
API 공통 요소
Request
1. Header
해당 request에 대한 추가정보를 담고 있는 곳
ex. request body의 총 길이
2. Query String & Path Parameter
Query String
특정 조건을 주어서 정제된 결과물을 호출하는 것
Path Parameter
API URI로 통신을 하는 것. 필요한 상황에 따라, 내가 원하는 정보에 따라 URI를 다르게 요청할 수 있다.
3. Body
해당 request의 실제 내용. body가 없는 request들도 많다.
Response
1. Status code
응답 상태를 나타내는 코드
ex. 200
2. Message
예외(error)의 경우 예외 메시지를 응답한다.
3. Data
정상(success)의 경우 실제 전송될 데이터를, 오류(fail)의 경우 유효성 검증에 실패한 데이터의 목록을 응답한다.
Cookie
Browser에서 참조할 수 있는 local에 저장되는 key-value 형태의 데이터 파일
쿠키 프로세스
- 브라우저에서 웹을 접속한다.
- 클라이언트가 요청한 웹페이지를 응답으로 받으면서 HTTP 헤더를 통해 해당 서버에서 제공하는 쿠키값을 응답으로 준다.(클라이언트는 해당 쿠키를 저장한다.)
- 클라이언트가 웹페이지를 요청한 서버에 재요청시 받았던 쿠키정보도 같이 HTTP 헤더에 담아서 요청한다.
- 서버는 클라이언트의 요청에서 쿠키값을 참고하여 비즈니스 로직을 수행한다.
CORS란?
CORS(Cross-Origin Resource Sharing)는 출처가 다른 자원들을 공유한다는 뜻으로, 한 출처에 있는 자원에서 다른 출처에 있는 자원에 접근하도록 하는 개념이다.
브라우저에서는 보안적인 이유로 다른 출처(cross-origin) HTTP 요청들을 제한한다. 그래서 cross-origin 요청을 하려면 서버의 동의가 필요하다. 만약 서버가 동의한다면 브라우저에서는 요청을 허락하고, 동의하지 않는다면 브라우저에서 거절한다.
이러한 허락을 구하고 거절하는 메커니즘을 HTTP-header를 이용해서 가능한데, 이를 CORS(Cross-Origin Resource Sharing)라고 부른다. 따라서 CORS는 브라우저에서 cross-origin 요청을 안전하게 할 수 있도록 하는 메커니즘이다.
+ 아래의 구성요소 중에서 Protocol + Host + Port 3가지가 같으면 동일 출처(Origin)라고 한다. 이 3가지 중 한 가지라도 다르면 다른 출처이다.
CORS가 필요한 이유
CORS가 없이 모든 곳에서 데이터를 요청할 수 있게 되면, 다른 사이트에서 원래 사이트를 흉내낼 수 있게 된다. 예를 들어서 기존 사이트와 완전히 동일하게 동작하도록 하여 사용자가 로그인을 하도록 만들고, 로그인했던 세션을 탈취하여 악의적으로 정보를 추출하거나 다른 사람의 정보를 입력하는 등 공격을 할 수 있다. 이렇나 공격을 할 수 없도록 브라우저에서 보호하고, 필요한 경우에만 서버와 협의하여 요청할 수 있도록 하기 위해서 CORS가 필요하다.
쿠키와 세션
쿠키
Browser에서 참조할 수 있는 local에 저장되는 key-value 형태의 데이터 파일
세션
서버에 클라이언트의 상태정보를 저장하는 기술로 논리적인 연결이라고 한다.
웹 서버에 클라이언트에 대한 정보를 저장하고 클라이언트에게는 클라이언트를 구분할 수 있는 Session ID를 부여한다.
쿠키 vs 세션
- 저장 위치 : Cookie는 Client 메모리 또는 파일에 저장, Session은 Server에 저장
- 저장 데이터: Cookie는 String만 저장할 수 있는 반면에 Session은 Object도 저장할 수 있다.
- 보안: Cookie는 Client에 저장된다는 점과 파일로 저장될 경우 탈취, 변조의 우려가 있어 보안에 취약하다. 반면 Session은 Client 정보 자체가 서버에 있어 안전하다.
- 라이프 사이클: Cookie는 브라우저를 종료해도 저장되어 있을 수 있는 반면, Session은 Server에서 만료 시간을 설정해서 지워버릴 수 있기도하고, Client에서 브라우저 종료시 Session ID를 날리기 때문에 더 이상 참조할 수 없어 전부 지워진다.
- 속도: Cookie는 Server에 요청시 Client에서 로컬에서 바로 참조 가능한 반면, Session은 제공받은 Session ID를 이용해서 Server에서 다시 데이터를 조회하므로 Cookie가 더 빠르다.
