REST API란? (Representational State Transfer)

웹에서 사용되는 데이터나 자원(Resourse)을 HTTP로 표현하고, HTTP 프로토콜을 통해 요청과 응답을 정의하는 방식이다.

웹 애플리케이션에서는 HTTP 메소드를 이용해 서버와 통신합니다. GET을 통해 웹 페이지나 데이터를 요청하고, POST로 새로운 글이나 데이터를 전송하거나 DELETE로 저장된 글이나 데이터를 삭제할 수 있습니다. 이처럼 클라이언트와 서버가 HTTP 통신을 할 때는 어떤 요청을 보내고 받느냐에 따라 메소드의 사용이 달라지며, 이런 사용은 아무런 규칙 없이 이루어지는 것이 아닙니다. 요청과 응답을 할 때, '제대로 보내고 받을 수 있는' 일종의 규약 프로토콜이 존재합니다.

→ 프로토콜
→ HTTP 메소드
→ HTTP 프로토콜, 메세지

따라서 HTTP 프로토콜 기반으로 요청과 응답에 따라 리소스를 주고받기 위해서는 알아보기 쉽고 잘 작성된 메뉴판이 필요한데, 이 역할을 API가 수행해야 하므로 서로 잘 알아볼 수 있도록 작성하는 것이 중요합니다.
→ API (메뉴판)

REST API 6가지 원칙

- HTTP 요청 시스템을 REST API 원칙에 맞춰 사용하자

HTTP 4가지 요청 방식

(다시 기억하기)
1. 읽기 / GET : 읽고 싶어요
2. 쓰기 / POST : 생성해주세요
3. 수정 / PUT : 수정해주세요
4. 삭제 / DELETE : 삭제해주세요

1번째 원칙 : Uniform Interface ← 가장중요

• 하나의 URL로는 한개의 데이터만 가져와야한다.
• URL만 보고 어떤 정보가 들어올지 예측가능하게
  ex)instagram.com/youngSeo/photos ← 인스타그램의 영서의 사진첩임을 바로 안다!

URL 이름짓기 원칙

• URL을 명사로 작성(추천)
• 하위문서를 나타낼땐 /사용 (/하위폴더처럼)
• 파일확장자(.html)쓰지말기
• 띄어쓰기는 대시(-) 이용
• 자료 하나당 하나의 URL

2. Client-server 역할 구분하기

• 브라우저 역할 : 요청 request → 고객은 URL 하나만 알면 서버에 있는 자료를 갖다쓸 수 있습니다.
• 서버 역할 : 응담 response

3. Stateless

• 요청들은 각각 독립적으로 처리되어야 한다.
• 요청1이 성공해야 요청2를 보내주고 그런 식으로 요청간의 의존성이 존재하는 코드는 NO!

즉, 요청하나 만으로 자료를 가져오기 충분하도록 요청에 필요한 모든 정보들을 실어 보내는게 좋다.

4. Cacheable (브라우저가 알아서 하는 행위)

• 요청을 통해 보내는 (이미지 등)자료들은 캐싱이 가능해야한다.
• 캐싱을 위한 버전 같은 것도 관리를 잘해야한다.
• 캐싱? 네이버를 방문하면 크롬 브라우저는 자동으로 자주 사용하는 이미지 파일, CSS 파일 등을 하드에 저장한다. (거의 바뀔일 없는 네이버 로고나 아이콘 같은 것) 네이버 방문할 때 네이버서버에 네이버 로고주세요~라고 요청하지 않고 하드에서 저장한 것을 불러오는 행위가 캐싱이다.
  

5. Layered System

요청처리하는곳, DB에 저장하는곳 이런 여러가지 단계를 거쳐서 요청을 처리해도 됩니다. (여러개의 레이어를 거쳐서 요청을 처리하게 만드는 것)

6. Code on Demand

서버는 고객에게 실제 실행가능한 코드를 전송해줄 수도 있습니다.