REST API가 뭔데?

준커·2023년 9월 9일
APIRESTRestful
0

Web

목록 보기
5/5
post-thumbnail

1. REST API란?

1-1. REST (Representational State Transfer)

Representational: 표현적인

State: 상태

Transfer: 전송

  • 네트워크 리소스를 정의하고 처리하는 방법을 설명하는 일련의 원칙을 기반으로 하는 소프트웨어 아키텍처 or 아키텍처 스타일
  • REST의 목적은, 개발자들이 함께 개발하기 때문에 통용되는 방식을 만드는 것이다.
  • RESTful하게 만든 API는 요청을 보내주는 주소만으로도 어떤걸 요청하는지 알 수 있다.

즉, 안전하고 신뢰할 수 있으며 효율적인 소프트웨어 통신 표준.

1-2. REST의 구성

  • 자원(Resource) - URI

    → URI에는 리소스에 대한 부분만 나타내야한다.

  • 행위(Verb) - HTTP 메소드

    → 행위에 대한 부분은 HTTP 메소드로 표현한다.

  • 표현(Representations)

    → 클라이언트 응답에 대한 반응을 서버는 표현해야한다.

    → REST에서 주로 JSON이나 XML로 표현함.

1-3. REST의 특징

Uniform (균일한 인터페이스)

요청이 URI로 지정한 리소스에 대한 요청으로 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일.

Stateless(무상태성)

  • API에 상태정보(세션 or 쿠키)를 따로 저장하고 관리 X

    → 즉, 각각 요청을 별개라고 생각하고 처리

    → 이전의 요청들과 현재의 요청이 연관되면 안됨.

    → API 서버는 들어오는 요청만을 단순히 처리

    → 서비스의 자유도 향상, 구현 단순.

Cacheable (캐시 가능)

  • HTTP 기존 웹표준을 그대로 사용 → HTTP에서 제공하는 캐시 기능을 그대로 이용하여 캐시를 구현 할 수 있음.

  • Last-Modified Tag 또는 E-Tag를 이용하여 캐싱을 구현할 수 있어서 대량 요청에 효율적

Self-descriptiveness (자체 표현 구조) → 현재는 제외됨.

  • API 메세지만 보고도 어떤 의도인지 파악가능.

Client-Server 구조

  • 관심사 분리를 위해 클라이언트-서버 구조로 구성.
  • 클라이언트는 서버에 리소스를 요청하고, 서버는 클라이언트의 요청을 처리하고 응답함.

계층형 구조

  • 서버는 보안, 로드 밸런싱, 암호화 계층을 추가해 구조상의 유연성을 둘 수 있고 PROXY, 게이트웨이 같은 네트워크 기반의 중간매체를 사용할 수 있게 함.

주문형 코드 (옵션)

  • 대부부분 XML or JSON으로 정적 표현을 보내지만 필요한 경우 실행가능한 코드를 요청할 수 있다.
    ex) 클라이언트가 API를 호출하여 UI 위젯 렌더링 코드를 받을 수 있다.

2. 난 잘 모르겠고 어떻게 하면 RESTful한건데?

행위와 자원을 철저하게 나누어야한다

2-1. 흔히 실수하는 예시

2-2. 🔥가장 중요 포인트🔥

  1. URI는 리소스만 담겨야함.
    ex) 미네랄을 캐라 → 미네랄이 리소스.

  • 이렇게 URI에는 리소스만 담겨야한다.

하지만

  • 리소스만 담기면 행위가 모호해지고 중복이 생김

이러한 중복을 구분해주는 것이 HTTP 메소드

  • 행위(캐라) 를 HTTP 메소드가 해줌!

3. HTTP 메소드의 종류

GET → 리소스 조회

GET /members

  • GET은 메세지 바디를 사용하지 않는다.
  • 원래 메세지 바디 지원 X → 현재는 지원되지만 지원되지 않는 곳이 많아서 권장 X
  • 멱등성 O
  • 캐시가능 O

POST → 요청 데이터 처리, 등록

POST /members

  • 메세지 바디를 통해 서버로 요청 데이터를 전달.
  • 주로 신규 리소스를 등록 할 때 사용.
  • 리소스를 변경할 때도 사용.
  • 멱등성 X
  • 프로세스를 처리해야 하는 경우에도 사용. ex) 배달 시작했다고 버튼 누를때
  • 다른 메소드로 처리하기 애매한 경우 → post는 만능!
  • 캐시가능 O BUT 바디 안에 데이터까지 캐시와 모두 맞춰야하기 때문에 실제로는 사용 X

PUT → 리소스를 대체, 해당 리소스가 없으면 생성

PUT /members/2

  • 클라이언트가 리소스를 식별 할 수 있음 → 정확한 결로를 알고 있다는 것이 POST와의 차이점.
  • 덮어쓰기이기 때문에 기존 리소스를 통째로 바꿀때도 사용 → 때문에 사용할때 주의해야함.

PATCH → 리소스 부분 변경

PATCH /members/2

  • 부분적으로 리소스의 내용을 바꿀 수 있음.
  • PATHCH가 지원이 안되는 곳도 있음 → POST로 부분 변경해야함.

DELETE → 리소스 삭제

DELETE /member/2

  • 리소스를 삭제한다.

4. 메소드 비교

4-1. GET vs POST

GET

  • 정보를 요청
  • 안전 O → 기존의 리소스가 바뀔 일이 없음
  • 멱등 O → 같은 호출이던 한번던 100번이던 최종 결과물이 같음.

POST

  • 정보를 등록
  • 안전 X → 리소스가 바뀜
  • 멱등 X → 두번 결재 → 중복결재로 처리되기 때문

++PUT은 → 멱등 O → 몇번을 결재해도 앞에 결재가 사라지고 새로운 결재로 덮어버리기 때문

4-2. POST vs PUT

PUT도 해당 리소스가 없으면 등록하는건 같은데 차이가 무엇인가?

  • 가장 명확한 차이는 클라이언트의 리소스 식별 유무이다.
  • POST는 클라이언트가 리소스를 식별X → 서버가 리소스의 위치를 결정한다. POST /members
  • PUT은 클라이언트가 리소스를 식별O → 클라이언트가 리소스의 위치를 결정한다. PUT /members/2

4-3. PUT vs PATCH

PUT도 기존 리소스 변경이고 PATCH도 기존 리소스 변경인데 차이가 무엇인가?

  • PUT
    • 기존에 있던 리소스를 덮어버림.
    • 기존 리소스가 name="a", age="20"에서 나이만 21로 변경하고 싶다면 name="a", age="21" 로 모든 리소스를 요청해야함.
    • age="20" 이렇게 이름을 제외하고 보내면 리소스에 name은 사라지고 age만 남게됨.
  • PATCH
    • 기존에 있던 리소스 중 원하는 부분만 수정.
    • 기존 리소스가 name="a", age="20"에서 나이만 21로 변경하고 싶다면 age="21" 로 나이만 보내도 무관함.
    • 단, 너무 오래된 곳에서는 PATCH를 지원안할 수도 있음 → 이 경우엔 POST로 변경해야함.

restfulapi.net의 한마디

ㅋ0ㅋ
All the above constraints help you build a truly RESTful API, and you should follow them. Still, at times, you may find yourself violating one or two constraints. Do not worry; you are still making a RESTful API – but not “truly RESTful.”

profile
준커
학부생일뿐
이전 포스트

Back-end Framework 선정 기준

0개의 댓글