RestfulAPI , GraphQL

성찬홍·2024년 11월 3일

1. RestfullAPI

: Restfull API는 A가 어떤 방식으로 요청하고, B가 어떤 방식으로 응답할지 지정해 놓은 다양한 형식들 중 하나입니다.

작업의 종류

(1) Create

: 정보를 생성해서 넣는 것

(2) Read
: 조회, 목록 또는 특정 정보를 조회하는 것

(3) Update

: 정보를 업데이트하는 것

(4) Delete

: 어떤 정보를 삭제하는 것

EX) URI 사용 예시

POSThttps://api.example.com/v1/infos새로운 정보 추가
GEThttps://api.example.com/v1/infos목록 받아오기
GEThttps://api.example.com/v1/infos/11인 정보 받아오기
PUThttps://api.example.com/v1/infos/1313인 정보 수정
PATCHhttps://api.example.com/v1/infos/1010 인 정보 변경
DELETEhttps://api.example.com/v1/info/5050인 정보 삭제

=> HTTP는 RestFull API의 필수 요소는 아니지만, Restfull API의 조건을 구현하기 용이하기에 현업에서 HTTP가 주로 사용된다.

  • GET, DELETE
    • 적은 양의 정보를 담을 수 있다.
    • 쿼리 파라메타를 통해 정보를 구분하여 가져올 수 있다.
  • POST , PUT ,PATCH
    • 많은 양의 정보를 담을 수 있다.
    • body라는 공간에 데이터를 실어 보낼 수 있다.

⇒ 각 메서드의 색상, 속성, URI를 통해 개발자들이 한 눈에 봐도 알아볼 수 있다.

[
      {
        "id":1,
        "code": "WD0003",
        "parentCode": "WITHDRAWAL",
        "name": "제공된 정보가 기대에 미치지 못했어요",
        "description": "제공된 정보가 기대에 미치지 못했어요",
        "orderNumber": 0,
        "tempVal1": "",
        "tempVal2": "",
        "tempVal3": ""
      },
      {
        "id":2,
        "code": "WD0001",
        "parentCode": "WITHDRAWAL",
        "name": "필요한 정보를 다 얻었어요",
        "description": "필요한 정보를 다 얻었어요",
        "orderNumber": 0,
        "tempVal1": "",
        "tempVal2": "",
        "tempVal3": ""
      },
  ]

특징

  • RestFull API는 JSON 형태의 구조화된 데이터를 사용한다.
  • Stateless (상태가 없는) 통신
    - 클라이언트의 상태 정보가 서버 정보에 저장되어야지 않아야 한다.
    • 클라이언트의 요청은 몇 번쨰 반복되든, 필요한 모든 내용을 포함하고 있어야한다.
  • Cacheability
    - 응답을 캐싱해두어서 , 가지고 있는 데이터를 DB에서 꺼내지 않고 보내줄 수 있다.

장점

  • 직관적이여서 개발자 간 협업에 용이하다
  • 확장성이 좋다.
    • 서버와 클라이언트 간 인터페이스가 명확하여 서로간의 의존성이 낮다
  • 재사용성
    • HTTP 프로토콜을 사용하기에 기존 웹 인프라를 그대로 이용 가능핟.
  • 유지보수에 용이
  • 캐시 기능
    • 서버 측 부하 분산에 좋다

단점

  • HTTP 프로토콜에 의존된다.
  • URI 설계가 복잡할 수 있다.
  • 상태 정보가 클라이언트 서버 간에 전솔될 수 있다.

2. GraphQL (질의를 하기 위한 언어)

: GraphQL은 애플리케이션 프로그래밍 인터페이스를 위한 쿼리 언어이자 서버측 런타임으로 클라이언트에게 요청한 만큼의 데이터를 제공하는데 우선 순위를 두며,API를 더욱 빠르고 유연하며 개발자 친화적으로 만들기 위해 설계되었다.

& 하나의 엔드포인트

: 일반적으로 POST 를 사용하며 ,하나의 엔드포인트를 사용한다.

(1) 데이터의 조회
: query

→ POST 메서드로 위와같이 요청을 보낸다.

→ query에서 요청한 데이터만을(클라이언트가 필요로 하는)정보만 받아와서
RestAPI의 오버페칭을 방지할 수 있다.

→ 하나의 요청으로는 모든 데이터를 받아오지 못하는 underfetching 문제가 발생하기도 한다.

( 세부적으로 요청을 하기에 , 여러 요청을 필요로 하게 되는 경우가 생김 )

(2) 데이터의 추가,수정,삭제
: mutation 사용
→ 좌측 사진과 같이 요청을 하면, 우측의 데이터가 생성,수정,삭제가 된다.

(3) 구독 (subscription)

: 구독을 신청하여, 해당 데이터에 대한 변경사항 알림을 받을 수 있다.

장점

  • 하나의 EndPoint로 한번의 요청으로 여러 API의 정보를 가져올 수 있다.
  • 피요한 데이터만 요청할 수 있다.

단점

  • 캐싱이 어려움
    • 요청들이 복잡하여 , 이를 기준으로 캐싱이 어렵다
  • 서버 부담
    • 복잡한 쿼리로 인해 서버에 부담이 될 수 있다.

참고

https://luvris2.tistory.com/530
https://www.redhat.com/ko/topics/api/what-is-graphql

https://www.youtube.com/watch?v=lYuWfoWD67Q

profile
꾸준한 개발자

0개의 댓글