3) REST 규약

1. REST

- REpresentational State of Transfer

소프트웨어의 아키텍쳐를 어떻게 형성할 지에 대한 가이드라인
6개의 가이드라인이 존재하는데, 이를 다 따르게 된다면 해당 소프트웨어 아키텍쳐를 RESTful하다고 한다.
cf. REST 외에도 SOAP같은 다른 가이드라인이 존재한다.
이 중 보통 많이 사용하는 것이 REST!

2. API와 REST

- RESTful API

• Web에서 활용하게 되는 API가 REST 가이드라인을 다 따른다면,
  해당 API를 RESTful API 라고 할 수 있다.
• REST의 6개 가이드라인을 전부 따르지 않더라도,
  어느정도 REST 제약(가이드라인)을 지킨다면 REST API라 불린다.
• API 간 원활한 이해, 활용 등을 위해 필요에 의해서 만든 가이드라인.
  때문에 지키는 것이 좋지만, 필수 조건은 X
• 현업에 갔을 때 API 구축에 대한 업무 받았을 때,
  'RESTful하게 만들어야 하나요?' 라고 물어볼 수 있다.
  • RESTful 하게 만드는 것이 시간 등 비용이 더 들기 때문.

3. HTTP(API)와 REST

- HTTP Request

• Web에서 소통 시에 HTTP는 규약에 따라 다양한 요청 보내고 응답 받는다.
• 이 때 HTTP 소통 규약에 가이드라인을 제공하는 것이 'REST'
• REST는 필수 조건 X
  따라서 HTTP Request 메소드 중 GET이나 POST 혹은 다른 HTTP 요청을 보내도 소통 결과에는 문제 발생하지 않는다.
  • 즉, 한 서버에서는 HTTP GET을 통해서 이미지 받을 수 있고,
    다른 서버에서는 HTTP POST를 통해 이미지 요청 받을 수 있음.
    다른 메소드를 사용했지만, 결과적으로는 둘 다 이미지 받을 수 있다.
  • 그러나 이렇게 API 따라 활용법이 다르면,
    여러 API를 사용할 때마다 해당 API의 활용법을 개별적으로 알아내야 한다는 문제가 발생한다.

• 보통 REST API를 작성했다고 하면, 이렇게 HTTP Request 메소드를 사용한다. (반드시 지켜야하는 필수불가결한 규칙은 아님)

  GET : 데이터 조회
  POST : 데이터 생성
  PATCH : 데이터를 업데이트(일부 변경)
  PUT : 데이터를 업데이트 (전체 변경)
  DELETE : 데이터를 삭제

• REST API 활용예시 : GET
  • GET 요청:
    • REST 에서 GET 요청은 정보나 리소스를 가지고 올 때만 사용하라고 제시되어 있다.
    • 즉, 서버에 기록된 데이터나 리소스를 변경하는 작업에서는 사용해서는 안된다는 뜻
  • GET 요청 예시:

    주소만 봐도 어떤 리소스를 가져오는지 파악할 수 있다.
    1. /users 서버에 기록된 유저들을 가져올 것이라 예상 가능
    2. /users?size=20&page=5 유저를 가지고 오되,
    추가 쿼리 파라미터(?뒤에 오는 항목들)을 통해 페이지와 개수를 정해주고 있음.
    3. /users/123 유저 목록 중 123에 일치하는 유저 가져올 것이라 예상 가능
    4. /users/123/address 3번에서 찾은 유저의 address 정보 가져올 것이라 예상 가능

- HTTP Response

• 대표적인 상태 코드(Status Code)
  • 200(ok)
  • 201(Created)
  • 202(Accepted)
  • 204(No Content)
  • 301(Moveed Permanently)