REST API
Representational State Transfer 라는 뜻 이며, Roy Fielding 라는 박사가 주장하는 *API 디자인 방법이며 총 6개의 원칙이 존재한다.
API란 Application Programming Interface 이라고 하며 서로 다른 프로그램간에 소통할 수 있게 도와주는 통신 규약을 뜻한다. '서버에게 요청해서 데이터 가져오는 방법' 이 바로 API다.
📌 6가지 원칙
1. Uniform Interface
인터페이스는 일관성이 있어야한다는 것인데,
하나의 URL로는 하나의 데이터를 가져와야함 (하나를 가져오기 위한 두개의 URL을 만들지 말자)
간결하고 예측가능하게 짜야함 (URL 하나를 알면 둘을 알게)
*URL 이름짓기 관습을 잘 따라야함
URL 이름짓기 관습
예시: facebook.com/bbc/photos, instagram.com/explore/tags/food
이 URL들은 페이스북이 매우 잘 만든 API이다, 왜냐면 facebook.com/bbc/photos 이거 딱봐도 BBC뉴스 페북계정의 사진첩인 느낌이 들고 한눈에 딱 보인다.
- 단어들을 동사보다는 명사 위주로 구성함
- 응용해서 다른 정보들을 쉽게 가져올 수 있을 정도로 일관성 있음
- 대충 봐도 어떤 정보가 들어올지 예측 가능함
- 띄어쓰기는 언더바_대신 대시-기호-사용
- 파일 확장자 쓰지 말기
- 하위 문서들을 뜻할 땐 / 기호를 사용함
2. Client-server 역할 구분하기
고객들은 그냥 URL 하나만 알면 서버에 있는 자료를 갖다쓸 수 있다.
고객에게 서버역할을 맡기거나 고객에게 DB에 있는 자료를 직접 꺼내라고 하든지 그런 식으로 코드를 짜시면 안된다.
3. Stateless
요청들은 각각 독립적으로 처리되어야한다. 요청1이 성공해야 요청2를 보내주고 그런 식으로 요청간의 의존성이 존재하는 코드를 짜시면 안된다.
다르게 말하면 요청하나 만으로 자료를 가져오기 충분하도록 요청에 필요한 모든 정보들을 실어 보내는게 좋다.
4. Cacheable
요청을 통해 보내는 자료들은 *캐싱이 가능해야하고 캐싱가능하다고 표시하거나 캐싱 기간을 설정해주어야 한다고 한다.
캐싱이란 자동으로 자주 사용하는 이미지파일, css 파일 등을 하드에 저장해놓고 따로 요청하지 않고 하드에서 불러오는 행위를 말함
5. Layered System
요청처리하는곳, DB에 저장하는곳 이런 여러가지 단계를 거쳐서 요청을 처리해도 된다.
즉, 여러개의 레이어를 거쳐서 요청을 처리하게 만들어도 된다.
6. Code on Demand
서버는 고객에게 실제 실행가능한 코드를 전송해줄 수도 있다.
자세한 내용은 다음에 REST API (2)로 다시한번 정리해야겠다, ✍🏻
