혹시나 잘못된 개념 전달이 있다면 댓글 부탁드립니다. 저의 성장의 도움이 됩니다

오늘의 Checkpoint

REST API

Representational State Transfer
API 디자인 제약 혹은 규칙

• 웹에서 사용되는 데이터나 자원 Resource를 HTTP URI로 표현
  -> 자원에 대한 주소를 정하는 방법
• HTTP 프로토콜 방식으로 요청과 응답 정의

cf. 서버와 클라이언트가 독립적으로 업그레이되더라도 호환을 위해 별도의 작업이 필요하지 않게 하기 위해 고안된 방식
-> 클라이언트는 데이터를 주고 받을 때 널리 사용되는 REST API를 이해하고 요청시 활용할 수 있어야함

An API that provides network-based access to resources via a uniform interface of self-descriptive messages containing hypertext to indicate potential state transitions might be part of an overall system that is a RESTful application.
-- Roy.T.Fielding

cf. 궁극적인 REST API는 데이터에 해석에 필요한 모든 정보가 담기게 표현하는 Self-descriptive를 통해 확장성이 좋아지고, HATEOAS의 late binding 특성을 활용하면 상태 링크를 변경할 수 있음
cf. HATEOAS : 애플리케이션의 상태는 하이퍼링크로 이동 가능
cf. Late Binding : 미리 상태 전이가 결정된 것이 아니라 이동 후에 다음 전이가 결정

REST API 성숙도 모델

REST API를 작성할 때 지켜야할 규칙 4단계(0~3단계)

level	RMM 특징	요약
0단계	HTTP 프로토콜 사용	HTTP 프로토콜을 적용한 기본 단계
1단계	개별 리소스와의 통신 준수	각기 다른 End Point 적용
2단계	HTTP 메서드 원칙 준수	적절한 HTTP 메서드 적용	HTTP API
3단계	HATEOAS 원칙 준수	응답에 상태 전이를 위한 새로운 링크 추가	REST API

cf. 실제로는 2단계까지만 적용되도 좋은 디자인

RMM 0단계 : HTTP 프로토콜 사용

RMM 1단계 : 개별 리소스와의 통신을 준수

각 각의 요청 URI를 다르게하여 각기 다른 End point를 설정

• End point

  • 리소스에 따라 분리
    : 리소스와 관련된 명사 형태의 단어 -> "어떤 리소스의 상태를 변화시키는가?"
    ex. 영화관 예매 seat/G10

  • 동사, HTTP 메서드 언급 X

• 응답의 bod부분에 자세한 내역 서술

  • 성공/실패 여부를 반환
  • 사용한 리스소의 정보 기술

RMM 2단계 : HTTP 메서드 원칙 준수

HTTP Messages에서 요청에 의한 동작 내용이 CRUD에 맞게 HTTP 메서드 적용

• HTTP 메서드

  • GET : Read -> 단순 조회. 데이터 변화 X
  • POST : Create
  • PUT : Update -> 교체(없으면 추가)
    PATCH : Update -> 부분 수정
  • DELETE : Delete
    cf. POST, PUT과 멱등성 idempotent

• 응답의 Status line에 명확한 상태코드와 상태 텍스트 적용
  ex. POST 요청은 '200'보다 '201 Created'로 더욱 명확하게 작성
  cf. 클라이언트가 관련된 리소스를 확인 할 수 있도록, header에 "location":"생성된 uri 추가" 같은 내역을 덧붙임)
  

RMM 3단계 : HATEOAS 원칙 준수

Hypertext As The Engine Of Application State
응답의 body 내부에 사용한 리소스와 성공/실패 여부 외에도 리소스의 URI를 포함한 요소를 추가로 기술
-> 응답에 상태 전이를 위한 링크를 넣으므로써 클라이언트에서는 새로운 기능에 접근할 수 있음
cf. HATEOAS : 애플리케이션의 상태는 하이퍼링크로 이동가능한 것

Open API와 API key

정부에서 제공하는 공공데이터에 접근하기 위한 API
: 공공데이터라도 가격, 일정량만 조회 가능 등 조건이 다르기 때문에 API를 확인해야함
-> 원하는 정보를 조회하고 해당 API의 이용 수칙을 참고하여 리소스에 접근 가능

ex. Open Weather Map, 공공데이터

API key

API의 접근 권한을 부여하는 방식으로 API key를 제공하기도 함
-> API key를 가진 사용자는 리소스에 접근이 가능하며, 데이터 요청할 때 같이 전달해야 응답을 받을 수 있음

참고

그런 REST API로 괜찮은가
구글 REST API 작성 가이드라인
마이크로소프트 REST API 작성 가이드라인

Query parameter vs Path parameter

GET 메서드의 경우 payload 대신 query parameter, path parameter로 필요한 리소스 전달

• query parameter
  : GET 메서드에서 필터처럼 조건으로 사용되며 URL의 ? 뒷부분
  ex. ?date=2022-08-10, GET /39th?age=25 -> 특정한 조건으로 필터링

• path parameter
  : GET 메서드에서 유일한 값을 지정할 때 사용
  ex. GET /people/49 -> id가 49인 대상 지목

오늘의 나

느낀점
찾아볼수록 어려운 내용이였다. 커리큘럼에서 나온 자료로 뭔가 부족한 것 같아서 더 찾아보는데 알것 같으면서도 더 어려워졌다. 3단계까지 가는게 거의 어려워서 보통 현업에서 REST라고 하지만 완전한 건 아니라는게 파면 팔수록 알것 같았다. 이상형은 있지만 결혼은 다른 사람과 하는 느낌이랄까?ㅋㅋ 게다가 생활코딩 보는데 fetch에 이 메세지를 쓰는 것 같아서 신기하기도 하고 ajax 부분을 보고 다시 REST API를 봐야할 것 같더라.
어제 다른 수업은 없고 이 내용 공부하고 블로깅하는 시간이었는데 여유로우면서도 더 알아갈수록 시간이 부족할것 같더라. 그래도 흐리멍텅하게 아는 것보다 한 부분이라도 명확하게 알아야 마음이 편하니까 더 알아봐야지.