REST API란?

🎈 REST의 개념

REST의 정의

• Representtational State Transfer

• 자원의 이름으로 구분하여 해당 자원의 상태를 주고 받는 모든 것
  (= 자원의 표현에 의한 상태 전달)

• REST는 기본적으로 웹의 의존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일

• HTTP URI를 통해 자원을 명시하고 HTTP Method를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것
  
  

❗ URI vs URL
URI는 URL을 포함

• URI (Uniform Resource Identifier)

  • 인터넷 상의 자원을 식별하기 위한 문자열의 구성

• URL (Uniform Resource Locator)
  - 인터넷 상 자원의 위치
  - 어떤 파일의 위치를 의미
  
  

REST의 장단점

장점

• HTTP 프로토콜의 인프라를 그대로 사용하므로 REST API 사용을 위한 별도의 인프라 구축 필요 없음

• HTTP 프로토콜 표준을 최대한 활용하여 여러 추가적인 장점을 함께 가져갈 수 있음

• HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능

• REST API 메세지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악할 수 있음

• 서버와 클라이언트 역할을 명확하게 분리

단점

• 표준 존재 X

• HTTP Method 형태가 제한적
  
  

REST가 필요한 이유

• 애플리케이션 분리 및 통합

• 다양한 클라이언트의 등장
  
  

REST 구성 요소

1. 자원(Resource): URI

   • 모든 자원에 고유한 ID가 존재하고 이 자원은 server에 존재

   • 자원을 구별하는 ID는 HTTP URI

   • Client는 URI를 이용해서 자원을 지정하고 해당 자원의 상태에 대한 조작을 server에 요청

2. 행위: HTTP Method

   • HTTP 프로토콜의 Method를 사용

   • HTTP 프로토콜은 GET, POST, PUT, DELETE와 같은 메서드 제공

3. 표현

   • Client가 자원의 상태에 대한 조작을 요청하면 Server는 이에 적절한 응답 보냄

   • Rest에서 하나의 자원은 JSON, XML.. 등 여러 형태의 Representation으로 나타냄

REST 특징

1. server-client

   • 클라이언트는 서버의 자세한 사항에 대해 신경 쓸 필요 없이 제공되는 인터페이스를 통해 접근하여 응답을 받음, 자신의 Context 관리

   • 서버는 클라이어트의 상태를 신경쓰지 않고 제공한 인터페이스에 대한 처리만 담당하여 요청이 들어올 때 그에 맞는 응답 제공

2. stateless(무상태)

   • 각각의 요청 시 클라이언트의 Context가 서버에 저장되지 않음

   • 상태 정보를 저장하지 않으면 각 API 서버는 들어오는 요청의 메시지로만 처리하면 되고 세션과 같은 Context 정보를 신경 쓸필요가 없기 때문에 구현이 단순해짐

   • 서버는 각각의 요청을 별개의 것으로 인식하고 처리해야하며 이전 요청이 다음 요청에 연관되어서는 안됨

3. Cacheable(캐시 처리 가능)

   • 웹 표준 HTTP 프로토콜 그대로 사용 -> 캐싱 기능 적용 가능

   • 구현은 HTTP 프로토콜 표준에서 사용하는 Last-Modified 태그나 E-Tag를 이용하면 캐싱 구현 가능

   • 캐시를 사용하게 되면 네트워크 응답 시간뿐만 아니라 REST 컴포넌트가 위치한 서버에 트랜잭션을 발생시키지 않기 때문에 전체 응답시간과 성능, 서버의 자원 사용률을 비약적으로 향상시킬 수 있음

4. Layered System(계층화)

   • REST Server는 다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 등을 위한 계층을 추가하여 구조를 변경할 수 있음

   • Proxy, Gateway와 같은 네트워크 기반의 중간매체를 사용할 수 있게 해줌

5. Code-On-Demand

   • 클라이언트는 리소스에 대한 표현을 응답으로 받고 처리해야하는데 어떻게 처리해야 하는지에 대한 code를 서버가 제공하는 것을 의미

6. Uniform Interface(인터페이스 일관성)

   • URI로 지정한 Resource에 대한 조작을 통일되고 한정적인 인터페이스로 수행

   • 클라이언트가 플랫폼에 무관하며 특정 언어나 기술에 종속받지 않음

   • REST API는 HTTP를 사용하는 모든 플랫폼에서 요청 가능, Loosely Coupling(느슨한 결함) 형태를 갖게됨

7. Self-Description(자체 표현)

   • REST Api는 요청 메세지만 보고도 이를 쉽게 이해할 수 있는 자체 표현 구조

---

🎈 REST API 개념

API

Application Programming Interface

REST API 정의

데이터와 기능의 집합을 제공하여 컴퓨터 프로그램간 상호작용을 촉진하며 서로 정보를 교환가능하도록 하는 것

REST API 특징

• REST 기반으로 시스템을 분산해 확장성과 재사용성을 높여 유지보수 및 운용을 편리하게 할 수 있음

• REST는 HTTP 표준을 기반으로 구현하므로
  HTTP를 지원하는 프로그램으로 클라이언트, 서버를 구현할 수 있음

REST API 설계 기본 규칙

• 도큐먼트: 객체 인스턴스나 데이터베이스 레코드와 유사
• 컬렉션: 서버에서 관리하는 디렉터리라는 리소스
• 스토어: 클라이언트에서 관리하는 리소스 저장소
  
  
• 도큐먼트 vs 컬렉션
  도큐먼트는 객체 하나, 컬렉션은 객체의 집합
  - /users/1/products/3에서 users, products 컬렉션과 1(id가 1번인 user), 3(id가 3번인 products)을 의미하는 도큐먼트로 구성

1. URI는 정보의 자원을 표현해야한다

   • resource는 동사보다는 명사, 대문자보다 소문자 사용
   • resource의 도큐먼트 이름으로는 단수 명사 사용
   • resource의 컬렉션 이름으로는 복수 명사 사용
   • resource의 스토어 이름으로는 복수명사 사용

2. 자원에 대한 행위는 HTTP Method로 표현

   • URI에 HTTP Method가 들어가면 안됨
   • URI에 행위에 대한 동사 표현이 들어가면 안됨
   • 경로 부분 중 변하는 부분은 유일한 값으로 대체

REST API 설계 규칙

1. /는 계층관계를 나타내는데 사용

2. URI 마지막 문자로는 /를 사용 X

3. -은 URI 가독성을 높이는데 사용 (불가피하게 긴 URI 경로 사용 시 하이픈 사용)

4. _은 URI에 사용하지 않음

5. URI 경로에는 소문자 적합

6. 파일확장자는 URI에 포함 X

7. 리소스 간 연관 관계가 있는 경우 리소스명/리소스ID/관계가 있는 다른 리소스명
   (일반적으로 소유 'has'의 관계를 표현할 때)

---

🎈 HTTP 상태 코드

MDN HTTP 상태 코드

상태코드
200 OK	클라이언트의 요청을 정상적으로 수행함
201 Created	클라이언트가 어떠한 리소스 생성을 요청, 해당 리소스가 성공적으로 생성됨
400 Bad Request	잘못된 문법으로 인하여 서버가 요청을 이해할 수 없음
401 Unauthorized	클라이언트가 인증되지 않은 상태에서 보호된 리소스를 요청했을 때 사용하는 응답코드
403 Forbidden	콘텐츠에 접근할 권리를 가지고 있지 않음 (401과 다르 점은 서버가 클라이언트가 누구인지 알고 있음)
404 Not Found	서버가 요청받은 리소스를 찾을 수 없을 때
500	서버에 문제가 있을 경우 사용

참고
https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html
https://ijbgo.tistory.com/20
https://mangkyu.tistory.com/46
https://velog.io/@kjh107704/REST-%EC%84%9C%EB%B2%84-REST-API%EB%9E%80