[TIL] RESTful API

👉 RESTful API

• 분산 시스템 설계를 위한 아키텍처 스타일 ( 아키텍처 스타일이라는 건 제약 조건의 집합)
  따라서 RESTful API는 REST 아키텍처 원칙을 모두 만족하는 API

> REST와 RESTful은 엄격하게 다른 의미

👉 필요한 이유

1. RESTful API를 서비스하기만 하면 어떤 다른 모듈 또는 애플리케이션들이라도 RESTful API를 통해 상호간에 통신을 할 수 있기 때문
2. WEB브라우저 외의 클라이언트를 위해서 (멀티 플랫폼)

   예를 들어 모바일 애플리케이션으로 html같은 파일을 보내는 것은 무겁고 브라우저가 모든 앱에 있는 것은 아니기 때문에 알맞지 않았는데 RESTful API를 사용하면서 데이터만 주고 받기 때문에 여러 클라이언트가 자유롭고 부담없이 데이터를 이용가능. 서버도 요청한 데이터만 깔끔하게 보내주면되기 때문에 가벼워지고 유지보수성이 좋아진다.
   참고 < https://jeong-pro.tistory.com/180 >

👉 REST의 구성 요소

HTTP URI = 자원
HTTP Method = 행동
MIME Type = 표현 방식

GET /100 HTTP/1.1
Host : jeong-pro.tistory.com

// URI = '/100' , HTTP Method = 'GET'
// MIME Type = Response Http head 메세지에 Content-type으로 쓰여진다 

👉 제약 조건

1. Client / Server
2. Stateless : 각 요청에 클라이언트의 context가 서버에 저장되어서는 안된다.
3. Cacheable : 클라이언트는 응답을 캐싱할 수 있어야 한다.
4. Layered System : 클라이언트는 서버에 직접 연결되었는지 미들웨어에 연결되었는지 알 필요가 없어야 한다.
5. Code on demand(option) : 서버에서 코드를 클라이언트에게 보내서 실행하게 할 수 있어야 한다.
6. uniform interface : 자원은 유일하게 식별가능해야 하고, HTTP Method로 표현을 담아야 하고, 메세지는 스스로를 설명해야한다. 또 하이퍼링크를 통해서 애플리케이션의 상태가 전이 되어야 한다.

[ RESTful 하려면 uniform interface를 잘 지켜야 한다. ]

RESTful API를 이용해서 하나의 큰 서비스 애플리케이션을 여러 모듈화된 작은 서비스 애플리케이션들로 나눌 수 있게 됐기 때문

URI = Uniform Resource Identifier / URL = Uniform Resource Locator
REST에서는 모든 것을 Resource로 표현. 그리고 그 자원은 유일한 것을 나타낸다. 반면에 과거의 웹에서는 Identifier의 개념이 따로 필요없었다. html같은 파일들을 주고 받았기 때문에 파일의 위치를 가리키는 Locator를 이용했다. URI가 파일 뿐만 아니라 여러 자원들 까지도 포함하는 개념으로 이해할 수 있다.

📃 정해진 규칙대로 routing 주소를 만들기 때문에 route 이름을 짓는 수고를 덜 수 있고, 통일성이 있다.

📃 API의 확장을 쉽게 할 수 있다