RESTful

RESTful은 REpresentational State Transfer의 약자로 2000년 Roy Fielding의 논문에 처음 정의하였으며, 핵심은 웹에 존재하는 모든 자원에 고유한 uri를 붙이자는 것이다.

즉 REST는 웹에 존재하는 자원에 주소를 지정하는 방법론 혹은 규칙이다.

RESTful API

본디 REST는 네트워크 통신을 위해 제시하였으나, 현실적으로 온라인 '네트워크'의 지분 중 태반을 차지하는게 월드 와이드 웹이기 때문에 '웹' 기반의 전송을 위해 쓰이는 경우가 대부분이다. 태생 자체가 데이터 송수신에 최적화 되어 있다보니 이를 위한 웹 API 쪽에서 굉장히 많이 쓰인다. 이를 'REST API'라고 부르는데, 이제는 그냥 '웹 API'와 동일하다고 볼 수 있을 정도로 보편화되었다. 어디선가 HTTP기반의 웹 API를 구현한다면 십중팔구는 REST를 준수하는 RESTful API라고 보면 된다.

조건

• Client-Server
  클라이언트와 서버로 분리되어야하며 서로 의존성이 없어야 한다.
  

• Stateless(무상태성)
  상태 정보를 따로 저장하지 않으며, 이용자가 누구인지 혹은 어디서 접근하는지와 관계 없이 결과가 무조건 동일해야 한다. 따라서 REST API는 필연적으로 오픈될 수 밖에 없다.

• Cache
  HTTP를 비롯한 네트워크 프로토콜에서 제공하는 캐싱 기능을 적용할 수 있어야 한다.

• Uniform Interface
  데이터가 표준 형식으로 전송될 수 있도록 구성 요소 간 통합 인터페이스를 사용한다. REST API 태반이 HTTP를 사용하기 때문에 HTTP 표준인 URL과 응답 코드, Request-Response Method 등을 사용한다.

• Layered System
  API는 REST 조건을 만족하면 필연적으로 오픈될 수 밖에 없기 때문에, 요청된 정보를 검색하는데 있어 계층 구조로 분리되어야 한다.

• Self-descriptiveness
  API를 통해 전송되는 내용은 별도 문서 없이 쉽게 이해할 수 있도록 자체 표현 구조를 지녀야 한다. 마찬가지로 웹 표준인 JSON과 XML이 절찬리에 사용중이다.

규칙

[GET] http://127.0.0.1:8000/product/main_page_product

• url은 자원 기준으로 작성한다.

• 메인페이지에 노출될 정보가 무엇인지 판별하여 url을 정한다.

• 한 번에 여러 종류의 정보를 노출해야 할 때, 프론트엔드 개발자와 상의 후 REST 기준에 맞춰 여러 엔드포인트를 호출한다.

[GET] http://127.0.0.1:8000/store/find_store

• 동사보다는 명사를 사용한다.

• GET POST PUT DELETE 메서드를 사용하면서 해당 단어를 엔드포인트 url에 넣지 않는다.

[GET] http://127.0.0.1:8000/store?name='강남'

• 검색 기능은 자원의 정보를 호출하는 기능이므로 [GET] method를 사용합니다.

• 검색 키워드는 body를 통해 전달하지 않고, query string을 활용합니다.

Query Parameters

• 웹 페이지의 url 주소를 자세히 보면 종종 ? 가 포함되어 있는 것을 볼 수 있다. 이 물음표는 단순한 문자열이 아니라, 특정한 기능을 수행하고 있다. 물음표 뒤에는 늘 key=value 형식의 문자열이 따라온다. 이를 Query parameter 라고 부른다.

• 주로 데이터를 조건으로 거르거나(filtering), 특정 방식으로 정렬하거나(sorting), 검색(searching)하고자 하는 경우에 활용된다.

참고

• 나무위키 https://namu.wiki/w/REST