[FE_Bootcamp] 33일차

오늘은 HTTP 통신에 쓰이는 API인 REST API에 대해 공부하였다.

네트워크는 정말 문외한이라 조금 어려웠지만, 한 블로그에서 꽤나 쉽게 풀어 설명해주신 글이 있어

다행히 보고도 모르는 사태는 벌어지진 않을 것 같지만.,,..,,,

promise부터 뭔가 심상치 않더니 계속해서 어려운 단원들의 연속,..,나살려

1. REST API

REST는 Representational State Transfer의 약자로, 웹에서 사용되는 데이터나 리소스(자원)를 URI로 표현한 뒤 HTTP 프로토콜을 통해 요청과 응답을 정의하는 방식을 말한다.

REST API는 이 REST 방식을 기반으로 만들어진 API이며, 다양한 규칙이 존재한다.

이 규칙들이 얼마나 지켜졌는지에 따라 0단계에서 3단계까지로 나뉘고, 단계가 높을수록 잘 디자인된 REST API라고 할 수 있다.

0단계는 단순히 'HTTP 프로토콜을 통해 통신하는 것'만 지키는 수준의 REST이다.

커피 주문을 예시로 들어 프로토콜 통신을 알아보자.

다만, HTTP를 통해 통신하는 과정은 REST API를 작성하기 위한 기본 단계이므로, HTTP로 통신한다고 해서 무조건 REST API가 될 수 있는 것은 아니다.

1단계에서는, 개별 리소스와의 통신을 준수해야 한다.

모든 자원은 개별 리소스에 맞는 엔드포인트(Endpoint)를 사용해야 하는데, 엔드포인트란 같은 URL들에 대해서도 다른 요청을 하게끔 구별하게 해주는 항목을 말한다.

클라이언트는 엔드포인트를 이용해 리소스를 요청하고, 서버는 받는 자원에 대한 정보를 응답으로 전달해야 한다

이 경우 엔드포인트가 menu/coffee이다. 이는 이미 커피 메뉴 중에서 메뉴를 고르고 있다는 것과 같다.

따라서 '차가운 음료'는 요청에 대해서도 '커피 메뉴 중 차가운 것'이라는 응답을 하는 것이다.

이번엔 커피를 시켜보자.

이번에는 엔드포인트가 beverage/11이다. 이는 beverage 리소스 중 11번 id를 가진 리소스가 변경되는 것을 나타낸다.

beverage/11에 해당하는 아메리카노의 orderd가 true로 바뀐 것을 볼 수 있다.

엔드포인트 작성 시에는 동사, HTTP 메서드, 혹은 어떤 행위에 대한 단어 사용은 지양하고, 리소스 자체에 집중해 명사 형태의 단어로 작성하는 것이 좋다.

더불어 요청에 따른 응답으로 리소스를 전달할 때에도 사용한 리소스에 대한 정보와 함께 리소스 사용에 대한 성공/실패 여부를 반환해야 한다.

2단계에서는 CRUD에 맞는 적절한 메서드를 사용해야 한다.

지난 시간에 C=POST, R=GET, U=PUT, D=DELETE라고 배웠었다.

그렇다면, 상황에 맞는 메서드를 사용해서 요청 및 응답을 보내보자.

단순히 차가운 커피의 종류를 알고 싶으므로, GET 메서드를 사용해 커피의 정보를 알아온다.

새로운 주문을 만드는 것이므로, POST 메서드를 사용한다.

이 메서드들을 이용할 때는 몇가지 규칙이 필요하다.

마지막 단계는 HATEOAS(Hypermedia As The Engine Of Application State)라는 약어로 표현되는 하이퍼미디어 컨트롤을 적용한다.

3단계의 요청은 2단계와 동일하지만, 응답에는 리소스의 URI를 포함한 링크를 작성해 전달한다.

이때 응답에 들어가게 되는 링크 요소는 응답을 받은 다음에 할 수 있는 다양한 액션들을 위해 많은 하이퍼미디어 컨트롤을 포함하고 있다.

GET 메서드를 이용해 커피의 종류를 받아온 뒤, 첨부되어 있는 링크를 통해 주문까지 한번에 할 수 있게 된다.

3단계는 필수가 아닌 옵션이고, 2단계까지만 잘 구현되어 있어도 좋은 REST API라고 말할 수 있다고 한다.

다만 HATEOAS를 사용하면 보다 쉽고 편리하게 리소스에 접근할 수 있을 것이다.