REST API
URI와 URL
URI (Uniform Resource Identifier)
: 통합 자원 식별자
자원을 나타내는 유일한 주소, 자원을 식별할 수 있는 문자열 고유하게 정보 리소스를 식별하고 위치를 지정; 하위 개념으로 URL, URN
어떤 자원의 위치를 의미하고 HTTP는 주어진 URI로 객체를 찾아오고 Method가 그 위치에 대한 행위를 뜻함
URL (Uniform Resource Locator)
: 통합 자원 지시자
특정 서버의 한 리소스에 대한 구체적인 위치를 서술, 네트워크 상 해당 자원이 어디 있는지 알려주는 규약
어떤 특정 지점의 위치 또는 파일 리소스(index.js, img.png..)에 접근하기 위한 주소
API
API (Application Programming Interface)
: 서버 애플리케이션의 기능을 사용하기 위한 방법/수단, 구현 방식을 알지 못해도 서비스가 서로 통신 가능
리소스에 대한 액세스 권한을 제공하고 보안과 제어를 유지할 수 있게 해주며 액세스 권한을 어떻게, 누구에게 제공할지 여부만 결정하면 됨
URI는 서버 설계 도면 / API는 서버 사용 설명서
URI는 서버 구성 요소를 나타냄
URI와 API 둘 다 명확하고 직관적이여야 타인이 볼 때 헷갈리지 않음
REST (Representational State Transfer)
: 웹의 창시자(HTTP) 중의 한 사람인 Roy Fielding의 2000년 논문에 의해서 소개
현재의 아키텍쳐가 웹의 본래 설계의 우수성을 많이 사용하지 못하고 있다고 판단하여 웹의 장점을 최대한 활용할 수 있는 네트워크 기반의 아키텍쳐 REST 원리를 따르는 시스템은 종종 RESTful이란 용어로 지칭
리소스 지향 아키텍쳐
모든 것을 리소스 즉 명사로 표현을 함
모든 형태의 명령이 명사형으로 정의가 가능한 것은 아니지만, 되도록이면 리소스 기반의 명사 형태로 정의를 하는게 REST형태의 디자인이 됨
REST API
Uniform Interface (유니폼 인터페이스)
: HTTP 표준에만 따른다면, 어떠한 기술이라던지 사용이 가능한 인터페이스 스타일
Stateless (무상태성)
: HTTP Session과 같은 컨텍스트 저장소에 상태 정보를 저장하지 않음, API 서버는 들어오는 요청만 메시지로만 처리하면 되며, 세션과 같은 정보를 신경 쓸 필요 없음
Layered System (계층형 구조)
: 대상 서버에 직접 연결되었는지, 또는 중간 서버를 통해 연결되었는지를 알 수 없음, 중간 서버는 로드 밸런싱 기능이나 공유 캐시 기능을 제공함
Self-Descriptiveness (자체 표현 구조)
: REST API 자체가 매우 쉬워서 API 메시지 자체만 보고도 API를 이해할 수 있음, 리소스와 메소드를 이용해서 어떤 메소드에 무슨 행위를 하는지를 알 수 없으며, 또한 메시지 포멧 역시 JSON을 이용해서 직관적으로 이해가 가능한 구조
Client-Server (클라이언트 서버 구조)
: REST 서버는 API를 제공하고, 제공된 API를 이용해서 비즈니스 로직 처리 및 저장을 책임짐
Cacheable (캐슁 가능)
: HTTP라는 기존의 웹 표준을 그대로 사용하기 때문에 캐슁 기능 적용 가능
API 문서
클라이언트에게 API 명세서를 제공해야함
문서 작성방법에는 다양한 방법(swagger, postman api)가 있지만 액셀(스프레드 시트)나 git wiki 추천
API 문서는 누가봐도 이해할 수 있도록 명확하고 직관적이어야 함
API 문서 구성 요소
1. API 이름
2. HTTP Method
3. Content-Type
4. URL
5. 요청 헤더 / 바디 (Request Header / Body)
6. 응답 바디 (Response Body)
