[Web]REST API와 GraphQL

Euiyeon Park·2024년 8월 16일
HTTP Response StatusRESTREST APITILgraphqlrestful apiweb
0

Web

목록 보기
2/13
post-thumbnail

웹의 본질

앞선 게시글에서도 언급했지만 웹의 본질은 요청과 반환, Request와 Response다.

HTTP 상에서 웹의 본질인 요청과 반환을 위해서는 REST API를 사용하는데, 몇가지 단점 보완을 위해
GraphQL도 사용한다.

REST와 REST API

RESTAPI

🤍REST

REST는 철학이다

REST는 월드 와이드 웹과 같은 분산 하이퍼미디어 시스템을 위한
소프트웨어 아키텍처의 한 형식으로

  1. REST는 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에
    웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일이며,
  2. REST는 네트워크 상에서 Client와 Server 사이의 통신 방식 중 하나이다.

REST는 REpresentational State Transfer의 약자로
자원을 이름으로 구분해 해당 자원의 상태(정보)를 주고받는 모든 것을 의미하는데,
자원의 표현에 의한 상태 전달 이란

  • 자원 : 해당 소프트웨어가 관리하는 모든 것(문서, 그림, 데이터 등)
  • 표현 : 그 자원을 표현하기 위한 이름(학생 정보가 자원이면, 'students'를 자원의 표현으로 정함)
  • 상태 전달 : 데이터가 요청되는 시점에 자원의 상태를 전달(JSON or XML)

💬REST의 구체적인 개념

HTTP URI를 통해 자원(Resource)를 명시하고, HTTP Method를 통해 해당 자원에 대한
CRUD Operation을 적용하는 것을 의미한다.

  • REST는 자원 기반의 구조(ROA, Resource Oreiented Architecture)설계의 중심에 Resource가 있고, HTTP Method를 통해 Resource를 처리하도록 설계된 아키텍처를 의미한다.

  • 웹 사이트의 이미지, 텍스트, DB내용 등 모든 자원에 고유한 ID인 HTTP URI를 부여한다.

    • 각 리소스는 상위/하위 리소스를 가질 수 있다.

💬REST의 구성 요소

웹의 요청(Request)는 URI와 Method로 구성된다.

1. URI(Resource)

'어떤 자원에 대하여'의 대상으로, 명사로 표현 가능한 것들이다.

URL, Location : 자원의 위치
URI, Identifier : 자원의 위치에서 특정 자원에 대한 고유 식별자

1.1 URI의 구성 /collection/document{id}/store/controller

URI의 구성 요소는 큰 범위에서 작은 범위로 좁혀간다.

collection : 범주/집합 (People)

document{id} : 범주 내 특정 대상 (Person)

  • 만약 Person이 '홍길동'일때, 길동이가 개명을 한다면? 대응할 수 없다.
  • 그래서 고유 식별자인 id값을 사용한다.
  • 따라서 데이터베이스를 구축할 때 반드시 각 항목마다 고유값이 만들어지도록 설계해야한다.

store : 범주 내 특정 대상을 꾸미는 요소로 document에 귀속된 정보를 의미한다.

  • API를 쓰고자하는 관심사에 따라 store가 변경된다

controller : method를 제외한 행위를 명시하며, method에 대한 의미를 강화한다

  • 필요에 따라 URI의 가장 마지막에 표현
  • /people/12/register (POST method의 의미를 강화)

1.2 URI의 변수

URI에서 매번 달라지는 값은 변수로 처리하는데 변수의 종류는 두 가지가 있다.

Path Variable

Path Variable은 URI 경로(Path)에 포함된 변수로 특정한 리소스를 식별할 때 사용된다.

  • GET / users / 123

Query Paramether

URI 경로 끝 ? 뒤에 이어지는 키-값 쌍으로 추가되는 데이터로
필터, 정렬, 페이지네이션, 검색 등 요청 세부사항을 지정할 때 사용된다.

  • / products?category=electronic&sort=price&order=asc
  • / books ?status=available

2. HTTP Method

(어떤 자원에 대해) '어떤 행위를 할 것인가?'로 동사로 표현 가능하다.
클라이언트는 자원에 대해 서버가 수행해야할 동작을 Method로 지정하여 요청을 보낸다.

UPDATE에는 두 가지 Method가 있는데, PUT과 PATCH이다.

  • PUT : 전반적인 수정
  • PATCH : 작은 단위 수정

3. Representation of Resource

클라이언트가 자원의 상태(정보)에 대한 조작을 요청하면
서버는 이에 적절한 응답을 보내는데,
이 때 응답 데이터의 형태는 JSON과 XML이다.

3.1 HTTP Response Status

서버의 응답에는 요청을 처리한 결과에 대한 상태코드가 함께 담겨온다.

  • 10X : 정보성 응답 - Informational Response
    • 임시 응답, 현재 클라이언트의 요청까지 처리됬으니 계속 진행
  • 20X : 성공 (응답 완료) - Successful Response
    • 클라이언트의 요청이 서버에서 성공적으로 처리
  • 30X : 리다이렉션 - Redirection
    • 완전한 처리를 위해서 추가 동작이 필요한 경우
    • 주로 서버의 주소 또는 요청한 URI의 웹 문서가 이동되었으니
      그 주소로 다시 시도하라는 의미
  • 40X : 권한 혹은 잘못된 접근 (유저의 잘못) - Client Error
    • 없는 페이지를 요청하는 등 클라이언트의 요청 메시지 내용이 잘못된 경우
  • 50X : 서버 내부 문제 - Server Error
    • 서버 사정으로 메시지 처리에 문제가 발생한 경우
    • 서버의 부하, DB 처리 과정 오류, 서버에서 익셉션이 발생하는 경우

💬REST의 특징

🌿REST 특징 자세히 알아보기

1. Client - Server

2. Stateless

3. Cacheable

4. Layerd System

5. Uniform Interface

6. Self-Descriptiveness

🤍REST API

REST가 철학이라면, REST API는 그 철학을 실제로 구현한 API를 의미한다.

💬REST API 디자인 가이드

1. URI는 정보의 자원을 표현해야 한다.

  • /users, /members

2. 자원에 대한 행위는 HTTP Method로 표현한다.

URI에 HTTP Method가 들어가거나, 행위에 대한 동사 표현이 들어가면 안된다.

  • ❌ /members/delete/1
  • ❌ /members/show/1
  • ✅ DELETE/members/1, GET/members/1

💬REST API 설계 원칙

  1. 슬래시 구분자(/)는 계층 관계를 표현하는데 사용
  2. URI 마지막 문자로 슬래시(/)를 포함하지 않는다.
  3. 하이픈(-)은 URI 가독성을 높이는데 사용
  4. 밑줄(_)은 URI에 사용하지 않는다.
  5. URI 경로에는 소문자가 적합
  6. 파일확장자는 URI에 포함하지 않는다.

💬리소스 간의 관계 표현 방법

REST 리소스 간에는 연관 관계가 있는 경우 다음과 같은 표현 방법을 사용한다.

/리스소명/리소스 ID/관계가 있는 다른 리소스명

  • GET: /users/{usersId}/devices (일반적으로 소유 has의 관계를 표현)

그럼 RESTful API는 뭐야?

🤍RESTful API

참고 REST API와 RESTful API가 명확한 차이가 있다고하는데, 아직은 잘 모르겠다 ,,
이 부분은 추후에 수정하도록 하자

REST의 특징, 설계 원칙을 잘 지켜 설계하는 것을 'RESTful하다'라고 표현한다.

RESTful의 의미를 바탕으로 RESTful API란 REST API의 설계 원칙을 잘 지켜 설계된 API를 말한다.

RESTful한 API 설계

  • URI 그 자체로도 어떤 행위를 하는지 알 수 있어야하고,

    • 각 요청이 응답 받고자 하는 정보, 리소스들이 어떤 관계를 갖는지 URI를 통해 파악이 가능하다.

  • 인간의 문장으로 치환 가능해야 한다.(직관적이다)

  • REST API의 설계 규칙을 따른다.

REST API의 단점

REST API는 HTTP Method와 URI를 통해 각 작업을 구분한다.
따라서

  • 요청의 내용을 직관적으로 알 수 있다는 장점이 있지만
  • 수많은 엔드 포인트를 관리해야된다는 단점이 있다.
    • 각 비지니스 도메인마다 수많은 API를 일일히 만들어야한다.
    • 유저 도메인에 대한 단순 API를 만든다하더라도 GET, POST, DELETE, PUT, PATCH 벌써 5개다.
    • 유저 도메인 + 결제 도메인 등 모두 합치면 하나의 서비스를 위해 백엔드 서버가 제공해야되는 API는 수십, 수백개가 된다.

GraphQL 위와 같은 REST API의 단점을 극복할 수 있다.

🤍GraphQL

  • GraphQL은 하나의 엔드포인트를 사용하고, 모든 요청을 POST메소드를 사용한다.

  • REST API는 리소스의 특정 항목에 대한 응답을 받을 것인지 선택하지 못해
    각 리소스의 모든 데이터가 반환되는 Overfetching이 발생한다.

  • 그러나 GraphQL은 리소스의 특정 항목에 대한 응답을 받을 것인지 선택 가능하다

    • GraphQL은 Query메세지를 POST Method로 전송
    • Query에서 요청한 데이터만 담고 그 외는 포함하지 않음
    • query: 조회
    • mutation : 추가, 수정, 삭제
    • subscription : 리소스 데이터 업데이트 시 알림

  • 클라이언트가 필요로 하는 정보만을 취사선택해서 서버에 요청한다.

    • 어떤 데이터를 반환할지 백엔드 개발자/API가 결정하지 않은다.
    • 클라이언트가 어떤 정보를 가져갈지 관심사에 따라 쿼리를 보낸다.

ref

Youtube_GraphQL 과 REST API 의 차이점
Velog_@somfist
Velog_@nosenal27
Tistroy_inpa
Tistory_dev-coco
Tistory_hahahoho5915
Naver_codingbarbie

profile
Euiyeon Park
"개발자는 해결사이자 발견자이다✨" - Michael C. Feathers
이전 포스트

[Web]웹 서버: Monolithic과 MSA

다음 포스트

[Web]REST의 특징

0개의 댓글