REST API
두 컴퓨터 시스템이 인터넷을 통해 정보를 안전하게 교환하기 위해 사용하는 인터페이스
REST는 Representational State Transfer (대표 상태 전송)의 줄임말로 애플리케이션 개발의 아키텍처 중 하나이다.
기본 개념
- 웹 애플리케이션 상에 존재하는 모든 리소스에 대해 고유의 URI를 부여하고
리소스는 미디어, DB데이터 등을 모두 포함합니다. - HTTP Method(GET, POST, PUT, DELETE)를 이용해 리소스에 대해 CRUD 명령을 적용
구성 요소
1. 자원(Resource)
자원은 서버에 존재하는 데이터의 총칭입니다
2. 행위(Verb)
행위는 클라이언트가 HTTP Method를 이용하여 자원을 조작하는 것을 의미합니다.
3. 표현(Representation)
클라이언트가 HTTP Method로 자원을 조작하면 서버가 그에 대한 응답(JSON, XML)을 보내는데 그것을 의미
특징
1. 서버-클라이언트 구조(Server-Client Architecture)
서버는 API 제공, 클라이언트는 유저에 대한 처리를 전담하는 구조를 가지기 때문에 서버와 클라이언트의 역할을 분명하게 구분할 수 있다.
2. 무상태성(Stateless)
HTTP를 이용하는 만큼 Stateless의 특성을 가집니다.
각각의 요청에 대한 정보를 저장하지 않고 별개의 요청으로 처리합니다. 덕분에 구현이 쉽고 서버의 부담을 덜어줄 수 있습니다.
3. 캐시 가능(Cacheable)
HTTP를 사용하기 때문에 웹의 기본 인프라를 사용할 수 있습니다. 캐시 기능을 이용해 같은 URI에 대한 반복된 요청을 효율적으로 처리할 수 있다.
4. 일관된 인터페이스(Uniform Interface)
HTTP를 사용할 수 있는 환경이라면 플랫폼에 상관없이 사용할 수 있고, 리소스의 타입에 상관 없이 같은 형태의 요청으로 처리된다.
5. 자체적인 표현 구조(Self-Descriptiveness)
JSON, XML 등을 이용하는 메세지 구조로 해당 메세지가 무엇을, 어떤 행위를 의미하는지 직관적으로 이해할 수 있다.
6. 계층 구조(Layered System)
클라이언트와 서버의 통신 사이에 보안이나 로드 밸런싱등을 위한 중간 계층을 추가할 수 있다.
로드 밸런싱
서버가 처리해야 할 업무 혹은 요청(Load)을 여러 대의 서버로 나누어(Balancing) 처리하는 것을 의미
장점
- HTTP를 사용하기 때문에 별도의 인프라를 구축할 필요가 없다.
- 클라이언트와 서버는 REST API를 통해 정보를 주고 받기 때문에 둘 간의 역할이 명확하게 분리된다.
- HTTP를 사용 가능한 환경이라면 플랫폼에 상관없이 사용 가능하다.
- 메세지가 자체적으로 무엇을 의미하는지 표현하고 있기 때문에 사용이 쉽다.
단점
- 명확한 표준이 없다. REST의 특징을 따르지 않으면서 REST API로 설계되는 이상한 API가 될 수 있어 관리가 어려울 수 있다.
- HTTP Method를 사용하기 때문에 CRUD라는 단순한 행위의 Method만 지원한다.
- REST에서는 리소스를 JSON, XML등의 형태로 표현하는데 이는 RDBMS와는 맞지 않는 형태입니다. 그래서 NoSQL쪽이 더 선호되는 추세입니다.
RDBMS
Relational DataBase Management system
관계형 데이터 베이스
ex) 일반적인 데이터베이스
NoSQL
Not only SQL
데이터 테이블간 관계가 없는 데이터 베이스
ex) Json 형태
무상태 프로토콜 (stateless)
서버가 클라이언트의 상태를 보존하지 않는 특징이다.
서버의 확장성에 용이하다는 장점이 있지만, 클라이언트가 추가 데이터를 전송해야 하는 단점이 있다.
ex) 클라이언트 요청1을 보낼 때, 데이터를 다 담아서 보내기 때문에 아무 서버나 호출할 수 있다.
URI (Uniform Resource Identifier)
자원을 구분하고 접근하기 위해 사용하는 유일한 식별자.
URI의 종류
- URL (Uniform Resource Locator) - 자원의 위치
자원의 위치(주소)로 자원을 식별한다. - URN (Uniform Resource Name)
자원에 이름을 붙여 식별한다.
URI의 구조
❗️뒤에 파라미터까지 전달해야 자원을 정확히 식별할 수 있기 때문에 쿼리 스트링을 포함한 전체가 URL에 해당한다.
scheme (protocol)
브라우저가 사용할 프로토콜. 대개 HTTP나 HTTPS
host
요청이 도달할 서버를 가르키는 주소. 일반적으로 도메인 네임을 사용하지만 IP address를 직접 사용할 수도 있다.
port
서버에서 프로그램(서비스)이 사용하는 소켓을 구분. http는 80, https 443
path
서버에서 자원의 경로
query string
서버에 전달할 파라미터. key=value 쌍으로 표기하고 복수 개의 경우 &로 구분한다.
fragment
html 요소의 id를 가르켜 해당 지점으로 스크롤을 이동한다.
🤔 모든 URI는 URL인가요?
아닙니다. URL은 URI의 한 종류이며 가장 흔한 형태입니다.
다시 말하면 URI는 개념이고 URL은 개념을 구현한 하나의 형태이다.
ex) URI > URL
CRUD
대부분의 컴퓨터 소프트웨어가 가지는 기본적인 데이터 처리 기능인 Create(생성), Read(읽기), Update(갱신), Delete(삭제)를 약자로 묶은 단어이다.
REST에서의 CRUD Operation(운영) 동작 예시
- Create : 데이터 생성(POST)
- Read : 데이터 조회(GET)
- Update : 데이터 수정(PUT, PATCH)
- Delete : 데이터 삭제(DELETE)
HTTP
웹 브라우저와 웹 서버가 HTML로 작성된 웹 페이지나 동영상, 음성 파일 등등을 주고받기 위한 프로토콜(통신규약)이다.
HTTP는 HyperText Transfer Protocol의 약자이다.
HTTPS는 HyperText Transfer Protocol Secure의 약자이다.
http
예전엔 http는 읽기 전용으로만 사용되고 중요한 문서들을 다룰일이 없었지만,
현재시대에는 개인정보,기밀 등등 엄청 중요한 정보들까지 http로 다룰 일이 많아지면서
http를 통해서 통신을 하고 있다면 누군가 내 정보를 보고있는 것으로 보면 된다.
https
하지만, https로 통신을 하고 있다면 전송하고 있는 내용을 가로챈다 하더라도
그 안에 무슨 내용이 담겨있는지는 사용자들만 알 수 있다.
왜냐면 암호화가 되어 있어 볼 수 없기 때문이다.
😱주의😱
http로 통신하고 있는 사이트에서 로그인을 요구한다면, 그 사이트는 이용하지 말아야한다.
클라이언트와 서버
클라이언트 : 웹 사용자의 인터넷 연결된 장치들과 웹에 접근하는 소프트웨어이다.(크롬,파이어폭스)
서버 : 웹페이지, 사이트 또는 앱을 저장하는 컴퓨터이다.
쉽게 비유하면 클라이언트는 종업원 서버는 요리사이다.
API Manager?
회사에서는 API를 관리해주는 api manager라는 파일이 존재한다.
모든 api 의 셋팅을 관리해주는 파일이라고 이해하면 될 것 같다.
실제로 각 api를 정의하는 파일에 apimanager를 임포트해서 정해진 형식에 벗어나지 않게 쓸 수 있게 도와주는 파일이다.
역할
Base URL 관리
- env 형태에 맞게 공통 된 서버 주소를 정의하여 cors 에러가 나는 것을 방지한다.
- 서버와 로컬로 맞춰볼 경우에 api manager에 있는 base Url 주소만 변경해서 관리하면 모든 api의 주소가 서버의 로컬로 맞춰주는 편한 점이 있었다.
- 서버가 분리되면서 base url을 여러개로 정의해놓고 쓰기 간편했다.
API configuration 셋팅
각 서버별로의 기본 셋팅값을 정의해놓을 수 있다.
API 초기값 셋팅
각 api에 무조건 필요한 초기값들을 기본으로 셋팅해주는 함수가 들어있다.
rest api 맞는 crud 통신 규격을 만들어준다.
공부를 하다보니 알게된 점이다.
REST에는 명확한 표준이 없다보니까 회사에서 이상한 API로 설계되지 않게 기본 틀을 만들어주는 함수를 만들어놨다.
공통 에러를 정의해준다.
서버에서 공통적으로 쓰이는 에러를 클라이언트가 알 수 있는 에러로 코드로 나타내주기 위해 에러를 정의해서 관리한다.
💁🏻♀️ API Manager를 쓰고 내가 느낀점
내가 했던 프로젝트 중에 서버가 2개로 나눠지게 되면서 서버 셋팅이 달라지는 경우가 생겼다.
모든 api 파일들을 다 수정하는 것이 아닌, api manager 파일에서 내가 어떤 서버를 쓸건지에 대한 값을 구분할 수 있게 옵셔널한 값으로 만들어서
서버 2개를 나눠쓸 수 있게 처리했던 경험이 있었는데, 진짜 너무 편했다.(코드의 퀄리티는 장담못함....)
한 곳에서 api 와 관련된 모든 정보를 관리하다보니 디버깅 하기도 쉬웠다.
에러코드도 정의가 다 되어있어서 api 마다의 에러를 내보낼때마다 정의하는 것이 아닌 공통적인 에러들도 관리할 수 있게 되어있어서 편했다.
특히나 api를 처음쓸때 get에 뭐가들어가야하고 post에 뭐가 들어가야되나 헷갈리는 경우가 많았는데
규격을 만들어놓고 회사에서는 타입스크립트도 쓰다보니까, 마우스를 위로 올렸을때 함수에 역할과 인자값 자리를 쉽게 알 수 있어서 편하게 개발했던 경험이었다.
