REST
REST란?
REST는 Representational State Transfer의 약자로 자원을 이름(자원의 표현)으로 구분하여 해당 자원의 상태(정보)를 주고받는 모든 것을 의미한다.
- 자원의 표현
- 자원 : 해당 소프트웨어가 관리하는 모든 것( Ex. 문서, 그림, 데이터 등)
- 자원의 표현 : 그 자원을 표현하기 위한 이름 ( Ex. DB의 사용자 정보가 자원이면 ‘users’를 자원의 표현으로 정하는 것)
- 상태(정보) 전달
- 데이터가 요청되는 시점에서 자원의 상태(정보)를 전달하며 JSON을 통해 데이터를 주고받는 것이 일반적이다.
구체적인 개념으로 HTTP URI를 통해 자원(Resource)을 명시하고 HTTP Method(GET, POST, PUT, DELETE, PATCH 등)를 통해 해당 자원(URI)에 대한 CRUD Operation을 적용하는 것이다. 즉, REST는 자원 기반의 구조 설계의 중심에 자원(Resource)이 있고 HTTP Method를 통해 해당 자원(Resource)을 처리하도록 설계된 아키텍처를 의미한다. 웹 사이트의 이미지, 텍스트, DB 내용 등의 모든 자원에 고유한 ID인 HTTP URI를 부여한다.
CRUD Operation 이란?
CRUD는 대부분의 소프트웨어가 가지는 기본적인 데이터 처리 기능을 의미하며 Create, Read, Update, Delete를 묶어서 CRUD라고 한다. REST에서 CRUD Operation 동작은 아래와 같다.
- Create : 데이터 생성(POST)
- Read : 데이터 조회(GET)
- Update : 데이터 수정(PUT, PATCH)
- Delete : 데이터 삭제(DELETE)
REST의 장단점
- 장점
- HTTP 프로토콜의 인프라를 그대로 사용하여 별도의 인프라를 구축할 필요가 없음
- HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능함
- REST API 메세지가 의도하는 바를 명확하게 나타내므로 의도를 쉽게 파악할 수 있음
- 서버와 클라이언트의 역할을 명확히 분리함
- 단점
- 표준이 존재하지 않음. 어떻게 작성해야 한다는 것이 정해져 있지 않음.
- 사용할 수 있는 메소드가 4가지 형태로 제한적임(HTTP Method 형태가 제한적)
REST가 필요한 이유
- 애플리케이션 분리 및 통합
- 다양한 클라이언트의 등장
- 기존의 view를 넘겨주는 방식으론 다양한 클라이언트에 적용하기 힘듦. REST는 데이터만 넘겨주므로 이런 걱정이 없음
- 다양한 브라우저, Android나 IOS 같은 모바일과도 통신을 할 수 있어야 하기 때문에 REST는 더욱 필요함
REST 구성 요소
- 자원(Resource) : URI
- 모든 자원은 고유한 ID가 존재하며 해당 자원은 서버에 존재한다.
- 자원을 구별하는 ID는 ‘/users/:user_id’와 같은 HTTP URI다.
- 클라이언트는 URI를 이용해서 자원을 지정하고 해당 자원의 상태(정보)에 대한 조작을 서버에 요청한다.
- 행위 : HTTP Method
- HTTP 프로토콜의 Method(GET, POST, PUT, DELETE 등)를 사용한다.
- 표현(Representation of Resource)
- 클라이언트가 자원의 상태(정보)에 대한 조작을 요청하면 서버는 적절한 응답을 보낸다.
- REST에서 하나의 자원은 JSON, XML, TEXT, RSS등 여러 형태의 Representation으로 나타내어질 수 있으며 JSON을 통해 데이터를 주고받는 경우가 일반적이다.
REST 특징
- Server-Client 구조
- 기존에 JSP같은거 보면 서버에서 view를 만들어서 보내주는 형식이었고 브라우저에서 그걸 보여주기만 했음. 근데 이젠 구분해서 데이터만 주고받는 것
- Stateless(HTTP 프로토콜 인프라를 그대로 사용하기 떄문)
- Cacheable(캐시 처리 가능)
- Layered System(계층화)
- Client는 REST API Server만 호출한다.
- REST Server는 다중 계층으로 구성될 수 있는데 API Server는 비즈니스 로직만 수행하고 그 앞단에 보안이나 로드밸런싱, 사용자 인증 등을 추가하여 구조적으로 유연성을 줄 수 있다.
- PROXY, 게이트웨이 같은 네트워크 기반의 중간 매체를 사용할 수 있다.
- Uniform Interface(인터페이스 일관성)
- URI로 지정한 자원에 대한 조작을 통일되고 한정적인 인터페이스로 수행한다.
- HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하므로 특정 언어나 기술에 종속되지 않는다.
- Code-On-Demand(optional)
- 서버로부터 스크립트를 받아서 클라이언트에서 실행한다.
- 반드시 충족할 필요는 없다.
REST API
위의 REST는 사전적인? 정의로 너무 어렵게 와닿았다. 아래는 비교적 쉽게 정리해 보았다.
API란?
Application Programming Interface의 약자이다. Interface는 기계와 인간의 소통창구로 컴퓨터에는 키보드와 마우스로 사용자가 명령을 넣고 그 결과와 정보를 받아오기 위한 모니터가 있는데 여기서 키보드, 마우스, 모니터가 Interface에 해당한다.
그렇다면 기계와 기계, 소프트웨어와 소프트웨어 간 소통할 수 있는 창구가 필요할 것이다. 만약 스마트폰 앱에서 기상청 서버로 “date:220418/place:seoul/which:temperature”과 같이 날짜, 장소, 조회할 내역을 표시해서 이 주소로 요청을 보내면 “degree:14” 와 같이 답이 올 거라는 메뉴얼이 있다면 누구든 이 메뉴얼을 활용해서 기상청 정보를 활용한 프로그램을 만들 수 있을 것이다. 이렇게 소프트웨어가 다른 소프트웨어로부터 지정된 형식으로 요청, 명령을 받을 수 있는 수단을 API라고 한다.
유저에게 보이는 부분인 프론트엔드에서 데이터를 가지고 있는 곳인 백엔드에 이런 API를 통해 데이터를 주고받는 것이다. 사람끼리 대화를 하는 것과 같이 이러한 데이터 양식으로 데이터를 주고받자라는 약속이 API로 소프트웨어 간 대화를 하기 위한 하나의 약속된 언어라고 생각하면 된다. 사람끼리는 밥 줘!라고 할 수 있지만 소프트웨어는 이렇게 안되기 때문에 밥 줘!라는 형식을 기상청 예시와 같이 메뉴얼을 만들어서 사용하는 것이다.
REST API란?
말 그대로 REST 형식의 API라는 의미이다. 과거 SOAP라는 복잡한 형식이 대체된 것이다. 여기서 REST의 가장 중요한 특징이 각각의 요청이 어떠한 동작이나 정보를 위한 것인지를 요청의 형태(모습) 그 자체로 알 수 있다는 것이다. 사실 기능만 동작하게 만든다면 아무도 이해하지 못하게 작성해도 되지만 서비스를 혼자서 만드는 것이 아니기 때문에 요청을 보내는 주소만으로도 대략 어떤 일을 하는 요청인지 파악이 가능하게 만들어야 한다.
가령 https://{도메인}/users/15라는 주소로 요청을 보내면 15번 사용자의 정보가 오겠구나라고 이해할 수 있듯이 말이다. 이렇게 자원을 구조와 함께 나타내는 이런 형태의 구분자를 URI라고 한다.
이제 여기에 조회뿐 아니라 새로운 사용자를 추가하거나 업데이트, 삭제하는 작업이 필요할 것이고 그게 REST에서 설명한 CRUD Operation이다.
REST API는 HTTP 규약에 따라 요청을 보내기에 GET, POST, PUT, DELETE, PATCH 등 여러 메소드를 사용하여 요청을 보낸다. POST, PUT, PATCH에는 body라는 저장 공간이 있어서 GET이나 DELETE보다 정보를 많이 넣을 수 있으며 비교적 안전하게 숨겨서 보낼 수 있다. 이 메소드들의 기능이 특정 용도에 제한되어 있지는 않기에 POST만 사용해서 읽고 쓰고 수정하고 삭제하는 등 모든 데이터 처리를 할 수는 있지만 REST는 누구든 해당 요청의 의도를 쉽게 파악할 수 있도록 목적에 따라 구분해서 사용해야 한다.
GET은 Read, POST는 Create, PUT과 PATCH는 Update, Delete는 DELETE에 해당한다. PUT과 PATCH의 차이점은 PUT은 정보를 통째로 바꿀 때, PATCH는 정보의 특정 부분만 변경할 때 사용한다.
REST의 규칙 중 하나로 URI는 동사가 아닌 명사들로 이루어져야 한다는 게 있다. 만약 GET으로 모든 요청을 처리해서 URI가 https://{도메인}/users/2/read, https://{도메인}/users/2/update와 같이 동사로 구분될 텐데 길어지고 깔끔하지 않기 때문에 명사들로 이루어져야 하는 암묵적인 규칙이 있다.
정리하자면 REST API는 개발자 사이에서 HTTP 요청을 보낼 때 어떤 URI에 어떤 HTTP 메소드를 사용할지에 대해 널리 지켜지는 약속이다. 형식이기 때문에 언어, 프레임워크, 기술 등에 영향을 받지 않고 이런 형식을 지켜서 데이터를 주고받을 수 있는 것이다.
REST API 설계 규칙
- 슬래시 구분자 “ / “는 계층 관계를 나타내는 데 사용한다.
- Ex) https://{도메인}/houses/apartments
- URI 마지막 문자로 “ / “를 포함하지 않는다.
- 하이픈 “ - “은 URI가독성을 높이는 데 사용하며 언더바 “_ “는 사용하지 않는다. 언더바는 가려서 안보일 수도 있기 때문에 가독성을 저하시키기 때문이다.
- URI 경로에는 소문자가 적합하다. 대문자 사용은 피하도록 한다.
- 파일 확장자는 URI에 포함시키지 않는다.
RESTful 이란?
RESTful은 REST라는 아키텍처를 구현하는 웹 서비스를 나타내기 위해 사용되는 용어로 REST API를 제공하는 웹 서비스를 RESTful 하다고 할 수 있다. 공식적으로 발표한 정의가 있는 것이 아니고 REST원리를 따르는 시스템은 RESTful이라는 용어를 사용한다.
위에서 언급한 POST나 GET 메소드 하나만 사용하여 REST API를 작성하는 경우 RESTful 하지 못한 것이다.
'Network' 카테고리의 다른 글
소켓 프로그래밍을 하다가 발생한 의문점(왜 내 서버 소켓은 브라우저의 요청 클릭 한 번에 두 개의 커넥션을 생성하나요..?) (0) | 2024.07.08 |
---|---|
로드밸런싱(Load Balancing)과 Nginx (0) | 2023.04.18 |
쿠키와 세션 특징 및 차이 (0) | 2023.04.18 |