해당 글은 공부하기 위해 작성한 글이고, 아래 두개의 링크를 보고 작성한 글임을 알려드립니다.
https://velog.io/@stampid/REST-API%EC%99%80-RESTful-API
https://meetup.toast.com/posts/92

1. REST API 란

---

REST란 Representational State Transfer 의 약자이다.

자원을 URI 로 표시하고 해당 자원의 상태를 주고 받는 것을 의미한다.

즉, REST API 란 REST 기반의 규칙들을 지켜서 설계된 API 이다.

REST API 를 RESTful API 라고도 하는 것 같다.

2. REST의 구성 요소

---

• 자원(Resource) : URI
• 행위(Verb) : HTTP Method
• 표현(Representations)

즉 Rest는 URI를 통해 자원을 표시하고, HTTP Method를 이용하여 해당 자원의 행위를 정해주며 그 결과를 받는 것을 말한다.

3. REST 특징

---

1. Uniform (유니폼 인터페이스)
   Uniform Interface는 URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일을 말한다.

2. Stateless (무상태성)
   작업을 위한 상태정보를 따로 저장하고 관리하지 않는다.
   세션 정보나 쿠키정보를 별도로 저장하고 관리하지 않기 때문에 API 서버는 들어오는 요청만 단순히 처리하면 된다.
   서버는 각각의 요청을 완전히 다른 것으로 인식하고 처리를 한다.
   때문에 서비스의 자유도가 높아지고 서버에서 불필요한 정보를 관리하지 않음으로써 구현이 단순해진다.

3. Cacheable (캐시 기능)
   HTTP의 기존 웹 표준을 그대로 사용하기 때문에 HTTP가 가진 캐싱 기능 적용이 가능하다.

4. Self-descriptiveness(자체 표현 구조)
   REST API 메시지만 보고도 이를 쉽게 이해 할 수 있는 자체 표현 구조로 되어 있다는 것입니다.

5. Client-Server 구조
   Rest 서버는 API 제공을 하고 클라이언트는 사용자 인증에 관련된 일들을 직접 관리한다.
   자원이 있는 쪽을 Server라고 하고 자원을 요청하는 쪽이 Client가 된다.
   서로간의 의존성이 줄어들기 때문에 역할이 확실하게 구분되어 개발해야 할 내용들이 명확해진다.

6. 계층형 구조
   클라이언트는 Rest API 서버만 호출한다.
   REST 서버는 다중 계층으로 구성될 수 있으면 로드 밸런싱, 암호화, 사용자 인증 등을 추가하여 구조상의 유연성을 둘 수 있다.

4. REST API 디자인

---

REST API 설계 시 가장 중요한 항목은 다음의 2가지로 요약할 수 있다. (이 두가지는 꼭 기억하자)

1. URI는 정보의 자원을 표현해야 한다.
2. 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE)로 표현한다.
   GET : 정보 가져오기
   POST : 정보 생성하기
   PUT : 정보 업데이트
   DELETE : 정보 삭제하기

5. REST API 설계 규칙

• URI는 정보의 자원을 표현해야 한다.
  URI는 자원을 표현하는데 중점을 두어야 한다. (URI에 delete, create, show ,,, 등을 넣는 건 좋지 않다.)

# 나쁜코드
GET courses/show/1

# 좋은코드
GET courses/1

• 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE)로 표현한다.
  URI에 자원의 행위에 대한 표현이 들어가지 않는 대신 HTTP Method를 통해 대신한다.

GET courses/1        # 1번 course 가져오기
POST courses         # course 생성
DELETE courses/1     # 1번 course 삭제

• 슬래시(/) 는 계층관계를 나타내는데 사용한다.

http://test.com/courses/teacher

• URI 마지막은 슬래시(/)를 사용하면 안 된다.

http://test.com/courses/teacher/ [x]
http://test.com/courses/teacher  [o]

• 하이픈(-) 은 URI 가독성을 높이는데 사용한다.
  URI를 쉽게 읽고 해석하기 위해, 불가피하게 긴 URI경로를 사용하게 된다면 하이픈(-)을 사용해 가독성을 높일 수 있다.

• 언더바(_) 는 URI에 사용하지 않는다.
  밑줄은 보기 어렵거나 밑줄 때문에 문자가 가려지기도 한다.
  그렇기 때문에 언더바(_) 대신 하이픈(-) 을 사용한다.

• URI 는 소문자를 사용한다.
  대소문자에 따라 다른 리소스로 인식하게 된다.

• 파일 확장자는 URI 에 포함하지 않는다.

http://test.com/courses/teacher.png [x]

6. HTTP 응답 코드

---

1. 2xx 성공

   • 200: 클라이언트의 요청을 정상적으로 수행함.
   • 201: 클라이언트에게 생성 작업을 요청 받았고, 생성 작업을 성공함.
   • 204: 요청은 성공 했지만 응답할 콘텐츠가 없음.

2. 3xx 리다이렉션

   • 301: 클라이언트가 요청한 리소스에 대한 URI가 영구적으로 변경되었을 때 사용함.
   • 302: 301과 같으나 임시적으로 주소가 바뀌었을 경우 사용함.
   • 304: 이전에 방문했을 때의 요청 결과와 다르지 않을 경우 사용함. 캐시된 페이지를 그대로 사용.
   • 307: 임시 페이지로 리다이렉트.

3. 4xx 클라이언트 오류

   • 400: 클라이언트가 올바르지 못한 요청을 보냄.
   • 401: 로그인을 하지 않아 페이지를 열 권한이 없음.
   • 403: 금지된 페이지, 로그인을 하든 안하든 접근할 수 없음. (관리자 페이지)
   • 404: 찾을 수 없는 페이지, 주소를 잘 못 입력했을 때 사용함.403 대신에 사용할 수도 있음.(해커들의 공격을 방지하고자 페이지가 없는 것처럼 위장함)
   • 408: 요청 시간이 초과됨.
   • 409: 서버가 요청을 처리하는 과정에서 충돌이 발생한 경우. (회원가입 중 중복된 아이디인 경우)
   • 410: 영구적으로 사용할 수 없는 페이지.

4. 5xx 서버 오류

   • 501: 해당 요청을 처리하는 기능이 만들어지지 않음.
   • 502: 서버로 가능 요청이 중간에서 유실된 경우.
   • 503: 서버가 터졌거나 유지 보수 중(유지 보수 중일때는 유지 보수중이라는 것을 알려주는 페이지로 전송해주는 것이 좋음)
   • 504: 서버 게이트웨이에 문제가 생겨 시간 초과가 된 경우.
   • 505: HTTP 버전이 달라 요청이 처리할 수 없음.