3) REST 규약

joy·2021년 7월 29일
0

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)
profile
세상의 긍정적 변화에 기여하기

0개의 댓글