📝 REST & REST API & RESTful 를 이해하고, 이를 바탕으로 REST API 프로젝트를 개발한 것에 관해 정리해보고자 합니다
REST
Representational State Transfer
: 자원(resource)의 표현(representation)에 의한 상태(state) 전달(transfer)
: 자원의 상태를 주고받는 것 (자원에 접근하는 방식을 정해놓은 규칙)
즉, REST란 필요한 자원에 접근하는 방식을 정해놓은 규칙이다.
이때 자원(데이터,이미지 등) 에 대한 CRUD 연산(소프트웨어의 기본적인 데이터 처리 기능)을 수행하기 위하여,
→ HTTP URI 를 통해 자원을 명시하고
→ HTTP Method (POST, GET, PUT, DELETE)를 통해 자원에 대한 행위 표현 및 자원에 대한 연산을 처리한다.
URI : 자원(resource)
HTTP METHOD : 행위(Verb), HTTP request가 의도하는 action 표현
Payload : HTTP request에서 보내는 데이터(body)
REST의 특징
-
Server-Client(서버-클라이언트 구조)
영역을 서버와 클라이언트로 분리함으로써, 서버가 처리할 부분이 줄어들고 여러 플랫폼과 유저 인터페이스 형태로 확장하기가 쉬워진다. 한 데이터를 가지고 앱,웹등 다양한 플랫폼으로 확장할 수 있다.
+) 서버는 클라이언트가 요청한 내용을 json 같이 약속된 형태로만 전달하고, 이를 가지고 클라이언트는 별도로 작업을 하여 사용자에게 제공하게 되는 형태이다. -
Stateless(무상태)
HTTP 프로토콜은 Stateless Protocol이므로 REST 역시 무상태성을 갖는다.
상태가 없다는 의미는 서버 기준에서 클라이언트의 상태(세션,쿠키)를 저장하지 않는다는 의미이다. 이를 통해 서버 처리 방식에 부담이 줄어들고 일관성이 부여되며 서비스의 자유도가 높아진다. -
Cacheable(캐시 처리 가능)
HTTP 프로토콜을 사용하므로 HTTP의 캐싱 기능을 적용할 수 있다. 캐시 사용을 통해 응답시간 단축 등 성능 향상이 이루어진다. -
Layered System(계층화)
REST Server는 Layered System 으로 구성할 수 있다. 순수 비즈니스 로직 뿐만이 아니라 로드밸런싱, 암호화, 사용자 인증 등을 추가하여 다중 계층으로 구성할 수 있다. Client는 이와 상관없이 REST API Server(연결된 부분)만 호출한다. -
Uniform Interface(인터페이스 일관성)
편의를 위한 인터페이스의 일정한 제약을 따르며 수행한다. HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다. -
Self-descriptiveness (자체 표현 구조)
메서드, URI로 이루어져있고 설계 규칙을 잘 지켜 RESTful한 API 이라면 REST API 메시지만 보고도 쉽게 이해 할 수 있는 자체 표현 구조로 되어있다.
(ex. HTTP GEThttp://www.mall.com/item/001요청의 경우http://www.mall.com라는 API에서 item 에 관한 정보를 HTTP 요청을 통해 받아온다는 것을 알 수 있다.)
REST의 장점
장점
- HTTP 프로토콜의 인프라를 그대로 사용하므로 REST API 사용을 위한 별도의 인프라를 구출할 필요가 없다.
- HTTP 프로토콜의 표준을 최대한 활용하여 여러 추가적인 장점을 함께 가져갈 수 있게 해 준다.
- HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다.
- Hypermedia API의 기본을 충실히 지키면서 범용성을 보장한다.
- REST API 메시지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악할 수 있다.
- 여러 가지 서비스 디자인에서 생길 수 있는 문제를 최소화한다.
- 서버와 클라이언트의 역할을 명확하게 분리한다.
단점
- 표준이 자체가 존재하지 않아 정의가 필요하다.
- 사용할 수 있는 메소드가 4가지밖에 없다.
- HTTP Method 형태가 제한적이다.
- 브라우저를 통해 테스트할 일이 많은 서비스라면 쉽게 고칠 수 있는 URL보다 Header 정보의 값을 처리해야 하므로 전문성이 요구된다.
- 구형 브라우저에서 호환이 되지 않아 지원해주지 못하는 동작이 많다.(익스플로어)
REST API
REST API 란 REST의 원리를 따르는 API를 의미한다.
REST의 특징을 기반으로 서비스 API를 구현한 것이다.
REST API의 특징
각 요청이 어떤 동작이나 정보를 위한 것인지를 그 요청의 모습 자체로 추론이 가능하다.
REST API 설계
첫째, URI 를 통해 자원을 명시하고
둘째, HTTP 메서드를 통해 자원에 대한 행위를 표현한다.
(자원: 소프트웨어가 관리하는 모든 것, 자원에 대한 행위:
또한, 정확한 응답의 상태코드(HTTP 응답 상태 코드)만으로도 많은 정보를 전달할 수가 있기 때문에 명확한 응답의 상태코드 값을 돌려주는 것도 중요하다. 잘 설계된 REST API는 URI가 잘 설계된 것 뿐만 아니라 리소스에 대한 응답을 잘 내어주는 것까지 포함되어야 한다.
REST API 설계 규칙 (주의할 점)
- URI는 동사보다는 명사를, 대문자보다는 소문자를 사용하여야 한다.
- 슬래시 구분자(/)는 계층 관계를 나타내는 데 사용한다.
- 마지막에 슬래시 (/)를 포함하지 않는다.
- 언더바(_) 대신 하이폰(-)을 사용한다.
- 파일확장자는 URI에 포함하지 않는다.
HTTP 응답 상태 코드
| 상태코드 | 의미 |
|---|---|
| 1xx (정보) | 요청을 받았으며 프로세스를 계속한다. |
| 2xx (성공) | 클라이언트가 요청한 동작을 수신하고 성공적으로 처리했음을 가리킨다. |
| 3xx (리다이렉션) | 클라이언트는 요청 완료를 위해 추가 작업 조치가 필요하다. |
| 4xx (클라이언트 오류) | 클라이언트에 오류가 있거나 요청을 처리할 수 없다. |
| 5xx (서버 오류) | 서버가 유효한 요청을 수행하지 못했음을 가리킨다. |
RESTful API
REST의 원리를 잘 따르는 시스템을 RESTful 이란 용어로 지칭된다.
REST API 와 RESTful API 의 차이는 REST의 설계 규칙을 잘 지켜서 설계된 API를 RESTful한 API 라고 한다.
REST API의 설계 규칙을 올바르게 지키지 못한 시스템은(ex.URI 규칙을 올바르게 지키지 않는 등) REST API를 사용하였지만 RESTful 하지 못한 시스템이라고 할 수 있다.
프로젝트에서의 적용✨
시작할 당시 클라이언트가 앱,웹 등 어떤 플랫폼으로 구현할지 정하지 않았었기에 REST API로 개발하게 되면 다양한 플랫폼으로의 확장이 가능하다는 장점이 있었고,
RESTful API 로 설계한다면 다른 애플리케이션들도 RESTful API를 통해 (서버가 데이터를 보내줌으로써) 상호간에 통신이 편리하다고 생각했기 때문에 REST API로 개발하게 되었다.
[참조]
https://khj93.tistory.com/entry/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-REST-API%EB%9E%80-REST-RESTful%EC%9D%B4%EB%9E%80
https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html
https://ko.wikipedia.org/wiki/HTTP_%EC%83%81%ED%83%9C_%EC%BD%94%EB%93%9C
https://velog.io/@couchcoding/%EA%B0%9C%EB%B0%9C-%EC%B4%88%EB%B3%B4%EB%A5%BC-%EC%9C%84%ED%95%9C-RESTful-API-%EC%84%A4%EA%B3%84-%EA%B0%80%EC%9D%B4%EB%93%9C
https://stitchcoding.tistory.com/21
https://www.lostcatbox.com/2021/01/19/basic-api/
https://evan-moon.github.io/2020/04/07/about-restful-api/
https://meetup.toast.com/posts/92 /img
https://www.mindinventory.com/blog/best-practices-rest-api-development/ /img
