채용 공고를 보면 RESTful API 설계가 가능하신 분 이라는 말을 자주 봤다.
그래서 오늘은 이거에 대해서 정리 시작
REST
REST 개념
- REpresentational State Transfer
- 자원의 이름(자원의 표현)으로 구분하여 해당 자원의 상태(정보를)를 주고 받는 모든 것
- HTTP URI를 통해 자원을 명시하고, HTTP Method(POST, GET, PUT< DELETE)를 통해 해당 자원에 대한 CRUD를 적용하는 것
- REST는 네트워크 상에서 클라이언트와 서버 사이의 통신 방식 중 하나다.
즉 자원의 표현에 의한 상태전달
CRUD
- Create : 생성(POST)
- Read : 조회(GET)
- Update : 수정(PUT)
- Delete : 삭제(DELETE)
- HEAD : header 정보 조회(HEAD)
이게 REST의 개념인데 나는 이 말이 사실 무슨 말인지 감도 안잡힌다.
좀 더 쉽게 정리된 글을 찾아보다 이런 설명을 발견했다.
모바일, PC, 어플리케이션 등 플랫폼에 상관 없이 데이터를 주고 받을 수 있도록 HTTP 프로토콜을 이용해 만든 Server-Client 아키텍처
클라이언트가 PC로 한정되어 있던 과거와 달리 스마트폰의 보편화와 새로운 플랫폼의 등장으로 인해 클라이언트의 유형이 다양해졌고, 각 플랫폼에 맞게 서버를 일일이 만드는 것이 굉장히 비효율적임을 느낀 이들이 HTTP 메소드들(GET, POST, PUT, DELETE)을 활용하여 어떤 플랫폼을 사용하든지 간에 클라이언트와 서버 간에 동일하게 데이터를 주고 받을 수 있는 아키텍처를 만들어 낸 것이다.
REST 구성요소
- 자원(Resource), URI
- 모든 자원은 고유한 ID를 가지고 서버에 존재한다.
- 자원을 구별하는 ID는 '/board/:board_idx'와 같은 HTTP URI다.
클라이언트는 URI를 이용해 자원을 지정한다.URL & URL
URL은 인터넷 상 자원의 위치
URI는 인터넷 상 자원을 식별하기 위한 문자열의 구성
URI는 URL을 포함한다. 조금 더 포괄적 범위
- 행위(Verb), Method
- HTTP 프로토콜의 Method를 사용한다.
- 클라이언트는 URI를 이용해 자원을 지정하고, 해당 자원을 조작하기 위해 Method를 사용하여 서버에 요청한다.
- GET, POST, DELETE, PUT 등
- 표현(Representation of Resource)
- 클라이언트와 서버가 데이터를 주고받는 형태로 JSON, XML, TEXT, RSS 등이 있다.
- 일반적으로 JSON, XML을 사용
REST 특징
- Server-Client (서버-클라이언트 구조)
Server : 자원이 있는 쪽
Client : 자원을 요청하는 쪽
- REST Server는 API를 제공하고 비즈니스 로직 처리 및 저장을 책임진다.
- Client는 사용자 인증, context(세션, 로그인 정보)등을 직접 관리하고 책임진다.
이처럼 역할이 확실하게 구분되기 때문에 클라이언트와 서버간 개발 내용이 명확해지고 서로 의존성이 줄어든다.
- Stateless (무상태)
- HTTP 프로토콜은 Stateless Protocol로 REST도 무상태성을 갖는다.
- 클라이언트의 context를 서버에 저장하지 않는다.
- 서버는 클라이언트의 요청을 단순 처리한다.
작업을 위한 세션 정보나 로그인 정보 등 쿠키 정보를 별도로 저장하고 관리하지 않아 서버는 들어오는 요청을 단순히 처리만 하면된다.
그래서 서비스의 자유도가 높아지고 서버에 불필요한 정보가 저장되지않아 구현이 단순해진다.
- Cacheable (캐시 처리)
- HTTP 프로토콜을 그대로 사용해 웹에서 사용하는 기존의 인프라를 그대로 활용할 수 있는데 그 중 가장 강력한 특징인 캐싱 기능을 적용할 수 있다.
HTTP 프로토콜에서 사용하는 Last-Modified Tag, E-Tag를 이용해 캐싱을 통해 대량의 요청을 효율적으로 처리할 수 있다.
- Layered System (계층 구조)
- 클라이언트는 REST API 서버만 호출한다.
- REST 서버는 다중 계층으로 구성될 수 있다.
- 보안, 암호화 등을 위한 계층을 추가해 구조를 변경할 수 있다.
- Proxy, Gateway와 같은 네트워크 기반 중간 매체를 사용할 수 있다.
하지만 클라이언트는 내가 지금 서버와 직접 통신하는지 중간 매체와 통신하는지 알 수 없다.
- Uniform Interface (인터페이스 일관성)
- URI로 지정한 자원(Resource)에 대한 요청을 통일되고, 한정적인 인터페이스로 수행하는 아키텍처 스타일
- HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하고 느슨한 결합 형태를 갖는다.
즉, 특정 언어나 기술에 종속되지 않는다.
- Self-Descriptiveness (자체 표현)
- 요청 메세지만 보고도 쉽게 이해할 수 있는 자체 표현 구조로 되어있다.
REST API
REST API 개념
- REST의 특징을 기반으로 서비스 API를 구현한 것
REST API 특징
각 요청이 어떤 동작이나 정보를 원하는지 그 요청의 모습 자체로 추론이 가능하다.
DELETE /user/3
🥲 : user 3을 지우라는 이야기구나~~
REST API 디자인
- URI는 정보의 자원을 표현해야 한다.
GET /board/1동사보다는 명사, 대문자보다는 소문자
-
자원에 대한 행위는 HTTP Method(GET, POST, PUT...)로 표현한다.
-
행위(Method)는 URI에 포함하지 않는다.
GET /board/delete/1 -> DELETE /board/1- 행위에 대한 동사 표현이 들어가면 안된다. (CRUD 기능을 나타내는 것은 URI에 사용하지 않는다.)
GET /board/show/1 -> GET /board/1
GET /board/insert/2 -> POST /board/2- 경로 부분 중 변하는 부분은 유일 값으로 대체한다.
글 생성 URI - POST /board
10번 글을 삭제하는 URI - DELETE /board/10- /(슬래시)로 계층 관계를 나타낸다.
https://naver.com/blog/myblog마지막 URI는 /를 포함하지 않는다.
https://naver.com/blog/myblog/ ------ (X)- URI에 포함되는 모든 글자는 자원의 유일한 식별자로 사용되어야 하고, URI가 다르다는 것은 자원도 다르다는 것이다.
자원이 다르면 URI도 달라져야 한다. - 밑줄(_)은 사용하지 않고, 하이픈(-)을 사용한다.
- 클라이언트는 해당 요청에 대한 실패, 처리 완료, 잘못된 요청 등에 대한 피드백을 받아야한다.
- 파일 확장자는 URI에 포함하지 않는다.
RESTful API
RESTful API 개념
RESTful은 REST의 설계 규칙을 잘 지켜서 설계된 API를 RESTful한 API라고 한다.
즉 REST의 원리를 잘 따르는 시스템을 RESTful이라는 용어로 지칭한다.
REST API의 목적
REST API의 목적은 이해하기 쉽고 사용하기 쉬운 API를 제작하는 것이다.
GET /deleteUserInfo/id?=3
DELETE /users/3두 요청은 모두 특정 회원의 정보를 삭제하는 API이다.
하지만 1번은 restful하지 못하다. API의 이해도를 떨어트릴 수 있으며, 확장성도 없다.
이처럼 REST API를 사용한다고 해서 성능이 향상되는 것은 아니다. API의 이해도 및 호환성을 높이는 것이 REST API의 목적이다.
출처
https://aws.amazon.com/ko/what-is/restful-api/
https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html
https://velog.io/@ellyheetov/REST-API
