REST API ( Representation State Tranfer)

데인·2022년 12월 2일
0

Study with Me

목록 보기
12/12
post-thumbnail
post-custom-banner

REST API ( Representation State Tranfer)

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

= 클라이언트가 이해하기 쉽게 알아보기 쉽고 잘 작성된 메뉴판같은 역할! 사실 3단계까지 가는건 쉽지 않음. 2단계까지만 적용해도 좋은 API디자인이다 ⇒ HTTP API라고 부름

0단계

그냥 HTTP프로토콜 사용하는 것. ⇒ REST API라고 말할 순 없고 그냥 기반..정도로 볼 수 있음
(HTTP프로토콜을 사용하고 있다. 그게 다다.)

1단계

  • 0단계에서 더 나아가 개별 리소스와의 통신 준수
  • REST API는 웹에서 사용되는 모든 데이터나 자원을 HTTP URI로 표현
    ⇒ 모든 자원은 개별 리소스에 맞는 엔드포인트를 사용해야함 + 받는 자원에 대한 정보를 응답으로 전달하라

  • 요청 = ‘예약 가능한 시간 (요청시 엔드포인트 : /doctors/허준)
    응답 = ‘의사 허준의 예약 가능한 시간대’
  • 요청 = ‘특정 시간에 예약’ (요청시 엔드포인트 : /slots/123
    응답 = 리소스 사용에 대한 성공/실패여부 (아래 예시 확인)

2단계

  • CRUD에 맞게 적절한 HTTP 메서드(요청)를 사용하는 것이 중요
  • 2단계 충족 조건
    예약 가능한 시간을 확인한다? ⇒ 예약 가능한 시간 조회(READ) ⇒ GET메서드 사용하여 요청
    특정 시간에 예약한다? ⇒ 특정 시간 예약 생성(CREATE) → POST로 요청 → 응답코드 : 201 Created +Location헤더에 작성된 URI를 통해 확인할 수 있게 함
    - CREATE?하려면 POST메서드에 대한 응답이 어떻게 반환되는지 중요
    • HTTP메서드 규칙
      • GET메서드 같은 경우 서버의 데이터를 변화시키지 않는 요청에만 사용 (조회만!)
      • POST메서드는 요청마다 새로운 리소스 생성
        PUT메서드는 요청마다 같은 리소스 반환 (교체의 용도 / 멱등하다)
        POST ≠ PUT(구분하기)
        PATCH는 수정의 용도
        PUT ≠ PUT (구분하기)

3단계

HATEOAS(Hypermedia As The Engine Of Application State)라는 하이퍼미디어 컨트롤 적용.
2단계 + 응답하는 리소스의 URI를 포함한 링크요소 삽입하여 작성

(응답 받은 다음 할 수 있는 다양한 액션들을 위해 많은 하이퍼미디어 컨트롤 포함)
(예. 허준이라는 의사 예약 가능 시간 확인 후 예약 가능한 링크 삽입
특정 시간에 예약을 완료하고 그 예약을 다시 확인할 수 있는 링크 삽입)

*응답 내에 새로운 링크를 넣어 새로운 기능에 접근할 수 있도록 하는 것!

+ OPEN API

정부에서 제공하는 공공데이터 (쉽게 접근할 수 있도록 OPEN API형태로 공공데이터 제공중)

OPEN API

→ 누구에게나 열려있는 API (근데 무제한 아님, 이용수칙 존재, 제한 사항 존재)

API Key

API 사용하려면 API Key가 필요하다(서버의 문을 여는 열쇠) (가끔 필요없을 수도 있음)

- API Key가 필요한 경우

로그인한 이용자에게 리소스에 접근할 수 있는 권한 → API Key형태로 제공
데이터를 요청할 때 API Key를 같이 전달해야 원하는 응답 받음.

profile
너무나 바쁜 걸 아직 갈 데가 많아 난. 호기심 가득한 세상을 다 펼쳐볼거야. Chase Me! - Dreamcatcher
post-custom-banner

0개의 댓글