Rest api를 사용하면서 개념을 제대로 잡아보질 않아서 이번에 프로젝트를 진행하면서 리펙토링 기간동안 공부해봤습니다.
그 전에는 Rest api는 통신 역할로 웹에서 데이터를 CRUD형식으로 사용하는 방법으로만 단순히 기억하고있었습니다. 그래서 이번계기로 틈틈히 rest가 무엇이고 rest api가 무엇인지 왜 쓰는지에 대해서 공부해보았습니다.
우선 REST가 무엇인지 그리고 장단점, REST API는 무엇인지 그것에대한 내용을 적어보겠습니다.
REST란?
-
REST의 정의
- 자원을 이름으로 구분하여 해당 자원의 상태를 주고 받는 모든 것을 의미
- 즉, 자원(resource)의 표현(representation)에 의한 상태 전달
- 자원의 표현
- 자원 : 해당 소프트웨어가 관리하는 모든 것
- 문서, 그림, 데이터, 해당 소프트웨어 자체 등
- 자원의 표현 : 그 자원을 표현하기 위한 이름
- DB의 학생 정보가 자원일 때, 'students'를 자원의 표현으로 정함.
- 상태(정보) 전달
- 데이터가 요청되어지는 시점에서 자원의 상태(정보)를 전달한다.
- JSON 혹은 XML를 통해 데이터를 주고 받는 것이 일반적이다.
- 월드 와이드 웹(www)과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 개발 아키텍처의 한 형식
- REST는 기본적으로 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일
- REST는 네트워크 상에서 Client와 Server 사이의 통신 방식 중 하나
-
REST의 구체적인 개념
- HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고, HTTP Method(Post, Get, Put, Delete)를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것을 의미
- Create : 데이터 생성(Post)
- Read : 데이터 조회(Get)
- Update : 데이터 수정(Put, Patch)
- Delete : 데이터 삭제(Delete)
- REST 구성 요소
- 자원(Resource) : HTTP URI
- 자원에 대한 행위(Verb) : HTTP Method
- 자원에 대한 행위의 내용 (Representations) : HTTP Message Pay Load
- REST의 장단점
- 장점
- HTTP 프로토콜의 인프라를 그대로 사용하므로 REST API 사용을 위한 별도의 인프라를 구출 할 필요가 없다
- HTTP 프로토콜의 표준을 최대한 활용하여 여러 추가적인 장점을 함계 가져갈 수 있게 해준다.
- HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능
- Hypermedia API의 기본을 충실히 지키면서 범용성을 보장
- REST API 메세지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악
- 여러 가지 서비스 디자인에서 생길 수 있는 문제를 최소화
- 서버와 클라이언트의 역할을 명확하게 분리
- 단점
- 표준이 자체가 존재하지 않아 정의가 필요함
- HTTP Method 형태가 제한적
- 브라우저를 통해 테스트할 일이 많은 서비스라면 쉽게 고칠 수 있는 URL보다 Header 정보의 값을 처리해야 하므로 전문성이 요구
- 구형 브라우저에서 호환이 되지 않아 지원해주지 못하는 동작이 많음.
- PUT, DELETE를 사용하지 못하는 부분
- pushState를 지원하지 않는 점
REST API란?
- API(Application Programming Interface)
- 데이터와 기능의 집합을 제공하여 컴퓨터 프로그램간 상호작용을 촉진하며, 서로 정보를 교환가능 하도록 하는 것
- REST API의 정의
- REST기반으로 서비스 API를 구현하는 것
- 최근 OPEN API(공공 데이터 등), 마이크로 서비스(하나의 큰 애플리케이션을 여러 개의 작은 애플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍처) 등을 제공하는 업체 대부분은 REST API를 제공한다.
- REST API의 특징
- 사내 시스템들도 REST 기반으로 시스템을 분산해 확장성과 재사용성을 높여 유지보수 및 운용을 편리하게 할 수 있음
- REST는 HTTP 표준을 기반으로 구현
앞선 내용은 블로그를 참고하면 쓸 수 있는 내용이다. 하지만 정말 REST API의 정의는 이것일까?라는 의문이 들어서 유튜브로 한 우아한테코 학생이 한 설명을 듣게되었다.
REST API 간략 설명
요약하자면 아래의 내용들과 같다.
논문에따르면
하지만 이러한 설명은 REST API 창시자(Roy Fielding)가 말하길..
CRUD에대한 내용은 한 적이 없고 HTTP 메서드는 REST가 아니라 웹의 아키텍처 스타일의 일부다.
HTTP에서 정의한 방식대로만 잘 쓴다면 REST는 딱히 할 말이 없다...
Roy Fielding이 말하길 REST API란?
-
REST 아키텍처 스타일에 부합하는 API
-
Server-Client(서버-클라이언트 구조)
-
Stateless(무상태)
-
Cacheable(캐시 처리 기능)
-
Layered System(계층화)
-
Uniform Interface(인터페이스 일관성)
-
자원에 대한 식별(identification of resources)
-
표현을 통한 자원에 대한 조작(manipulation of resources through representations)
-
표현 : 특정한 상태의 자원에 대한 표현
-
클라이언트가 서버에 GET /user/1 HTTP/1.1를 보내면 자원의 현재 상태에 대한 표현을 서버에서 해준다.
-
반면 자원의 기대되는 상대(이미지)를 POST하면 새로운 임시 자원을 생성하고 식별자를 할당
-
Representational State Transfer(표현된 (자원의)상태)
-
자기 서술적인 메세지(self-descriptive messages)
-
HATEOAS(Hypermedia as the engine of application state)
- 하이퍼미디어를 통한 앱 상태 변경
- 위배 사례
- 숨겨진 페이지, 경로가 존재가 존재하면 HATEOAS 위배
- 프론트와 백엔드 사이에 일반적으로 JSON형태의 데이터를 주고받음
- HATEOAS위배한 경우가 대다수임
- 서버에 보낼 수 있는 요청들에 대한 정보를 Client에 보낼 수 있다면 위배되지않음
-
REST API여야 하는가?
- Uniform Interface 제약조건은 비효율적
- 애플리케이션에 필요한 정보가 아니라, 표준화된 형식으로 데이터 전달
- 상황에 따라 최적이 아닐 수 없음
-
API 설계의 방향성
-
진짜 REST API 만들기(RESTful API)
-
REST 스타일의 API 만들기(HTTP API)
- REST 제약조건 부분적으로 준수
- HTTP 스펙 적절하게 활용
- API 설계에 관한 컨벤션 참고
-
다른 API 표준 선택하기(Graphql API)
그런 REST API로 괜찮은가?
우아한 테코에서 발표한 REST API를 보면서 추천해주는 영상
이 블로그에서 내용들을 영상의 내용들을 정리해줌
이 영상과 내용들을 읽으면서 data와 header부분의 쓰임들을 알게되었고 api에서 http api로 쓰이는 내용과 REST API로 쓰이는 부분들에서 다른 방식들을 보게되었습니다.아직까지는 내용들을 읽어봐도 잘 모르는 입문자이기때문에 계속해서 돌려보고 제가 쓴 코드는 어떤 API를 썻는가?라는 의문점으로 공부를 해야될 것 같습니다.