REST API는 조금 배우고 나서 까먹고 있다가 네트워크나 데이터베이스를 공부하는데 항상 언급 되는 Rest API가 눈에 계속 보였다.
이번에 꼭 블로깅하면서 공부하면서 좀더 기억을 해놓아야 마음이 편할것같아 이렇게 블로깅합니다.
REST란
출처 : https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html
즉 REST는
HTTP URI로 자원을 명시하며, HTTP Method를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것이다.
-> 수정 : 명확하게 말하자면 REST API가 아니라고 한다.
단순하게 말하면 HTTP를 잘 사용하기 위한 아키텍쳐 스타일이라고 한다.
출처 : https://thalals.tistory.com/335
- HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다.
HTTP Method : POST,GET,PUT,DELETE,PATCH
CRUD Operation :
Create ->데이터 생성(POST)
Read -> 데이터 조회(GET)
Update -> 데이터 수정(PUT,PATCH)
Delete -> 데이터 삭제(DELETE)
구성 요소
- 자원 : HTTP URI
- 자원에 대한 행위 : HTTP Method
- 리소스(메소드 내용) : 클라이언트에서 자원의 상태를 조작하는 요청을 하고 서버에서 요청 처리하고 응답을 보낸다.
REST 디자인 원칙?(특징)
- Server -client
서버-클라이언트 구조
- 자원이 있는쪽이 Server, 자원을 요청하는 쪽이 Client
- 서로간의 의존성을 줄이면서 완전 독립적이어야한다. 서로 알아야할건 요청된 리소스의 URI.
- Stateless
무상태
- 클라이언트의 context를 server에 저장하지 않는다.
-> 세션과 쿠키와 같은 context 정보를 신경 안써도 되니 구현이 단순해짐.
- Cacheable
캐시 처리 가능
- 웹 표준 HTTP 프로토콜을 그대로 사용하므로 웹에서 사용하는 기존의 인프라를 그대로 활용할 수 있다.
-> HTTP 특징인 캐싱 기능을 적용할수 있다. - 서버 응답에는 전달된 리소스에 대해 캐싱이 허용되는지 여부에 대한 정보도 포함되어야 합니다.
- 이 목적은 서버측의 확장성 증가와 클라이언트 측의 성능 향상임.
-> 캐시 사용이 응답시간이 빨라지고 REST Server 트랜잭션이 발생 안해서 전체 응답시간, 성능,서버의 리소스 이용률을 향상시킴.
- Layered System
계층화
Client는 REST API Server만 호출한다.
-> 호출과 응답이 서로 다른 계층을 통한다.
- 엔드 애플리케이션또는 중개자와 통신 여부를 클라이언트나 서버가 알 수 없도록 설계해야한다.
- Uniform Interface
인터페이스 일관성
- URI로 지정한 Resource에 대한 조작을 통일시켜 요청이 어디서 오는지 동일한 리소스에 대한 API 요청은 동일하게 보여야한다.
- 클라이언트 - 서버 구조의 결합도를 낮추기 위함.
- HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용 가능하다.
API란
그럼 API는 무엇인가?
- Application Programming Interface
애플리케이션이나 디바이스가 서로 간 연결해서 통신할수 있는 방법을 정해놓은 규칙이다.
API는 프로그램과 프로그램을 이어주는 매개체다
-> 연결 통로
REST API란
그러니까 REST 방식으로 데이터를 상호 교환할수 있게 설계한 API다.
디자인 설계 단계
출처 : https://ibks-platform.tistory.com/292
0단계
출처 :https://ibks-platform.tistory.com/292
단순한 HTTP 프로토콜를 사용한 단계
- 하지만 REST API라고는 할수 없지만 좋은 REST API를 작성하기 위한 기본 단계
- HTTP의 수많은 기능들을 무시하고 데이터 통신하는 용도
예제)
1단계
출처 :https://ibks-platform.tistory.com/292
개별 리소스와의 통신을 준수해야함
즉 모든 자원은 개별 리소스에 맞는 엔드포인트를 사용해야하고 요청하고 받은 자원에 대한 정보를 응답으로 전달해야한다.
예를 들어 posts/1 처럼 posts라는 리소스를 만들어 1번 멤버라는 리소스가 보이도록 URI를 설계해야한다.
- 리소스 사용에 대한 실패 했을때 실패 여불를 포함해서 응답을 받아야한다.
2단계
출처 :https://ibks-platform.tistory.com/292
CRUD에 맞게 적절한 HTTP 메서드를 사용하는 것에 중점을 둔다.
0,1단계는 CRUD에 상관없이 POST하고 있었다.
- 동일한 리소스이지만, HTTP Method로 행위가 정해진다.
- HTTP Status code로 응답에 대한 결과 처리가 가능하다.
- 3단계까지는 잘 안하고 2단계를 많이 한다.
3단계
출처 :https://ibks-platform.tistory.com/292
HATEOAS(Hypertext As The Engine Of Application
State)라는 약어로 표현되는 하이퍼미디어 컨트롤을 적용한다.
- HATEOAS : 특정 API를 요청한 뒤 클라이언트 입장에서 이 응답을 받은 다음 단계로 할수 있는 작업을 알려주는것.
-> 다음 단계 작업을 위한 리소스의 URI를 서버에서 제공하는 것이다. - 3단계는 클라이언트는 다음 단계에 대한 행위를 클라이언트에서 관여안하고 서버에 응답으로서 행위를 정의할수 있게 된다.
- 2단계와 동일하지만 응답에는 리소스의 URI를 포함한 링크 요소를 삽입해 작성하는것이 다르다.
RESTfull이란?
출처 : 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
REST의 원리를 따르는 시스템.
- REST API를 제공하는 웹서비스를 RESTful하다고 할수 있다.
목적
- 이해 하기 쉽고 사용하기 쉬운 REST API를 만드는것이다.
- RESTful한 API를 구현하는 근본적인 목적은 일관적인 컨벤션을 통한 API의 이해도 및 호환성을 높이는것이기에 성능이 중요한 상황에선 굳이 구현할 필요없다.
해당 안되는 경우
- 모든 CRUD 기능을 POST로 처리하는 API
- URI 규칙을 올바르게 지키지 않은 API
후기
그동안 REST API는 자세하게 몰랐지만, 우리가 자주 쓰고 있던게 REST API고, 2단계인건 확실하다.
References
