Restful

이수연·2023년 4월 4일
Restfulfrontendhttp
3

안녕하세요. 최근에 저는 CS 공부를 하면서, 이론적인 부분은 이해는 되지만 구체적으로 말로 설명하는 것이 어려운 느낌이 들었습니다. 이로 인해 많은 고민을 하게 되었습니다. 이에따라 혼자 공부하는것보다 같이 공부하고 잘못 이해한 부분을 피드백 받기위하여 cs스터디에 들어가게 되었고, restful과 쿠키,세션,캐시 파트를 나눠서 포스팅 하려 합니다.
먼저 Restful과 soap의 차이점 그리고 restful의 특징 그리고 retful을 이용하여 어떻게 서버와 클라이언트가 통신하는지 정리해서 설명하겠습니다.

restful이란?

그럼 이제 본문으로 돌아와서 여러분은 restful을 뭐라고 생각 하시나요?? 저는 부트캠프 들어오기전, 단순히 프론트와 백엔드에서 요청과 응답을 하는것 이라고만 생각했습니다. restful은 요청 리소스 중심의 계층적 uri구조 입니다. 풀어서 설명하면 클라이언트와 서버 간 통신을 위한 개발자들의 약속 입니다. restful은 일상생활 어디서나 볼수 있습니다. 예를들어 우리가 은행에 가서 계좌를 확인할때 서버는 이요청을 받고 계좌 잔액 정보를 포함한 응답을 생성하여 클라이언트에게 보냅니다. 이렇게 개념만 설명 하는것 보다 모든것들이 나오기 시작한것은 사람들이 불편한점을 보안하기 나온것 이기 때문에, 단순히 의미만 아는것이 아니라, 역사에 대해 알아보고, retful정리,클라이언트에서의 restful 이렇게 세가지의 챕터로 나누어서 설명해 드리려 합니다.

Restful의 역사

초기에는 Get방식을 통하여 웹 통신을 했습니다. 그이유는 웹을 통해 텍스트로 이뤄진 문서만 보는것이 목적이었기 때문이죠! 클라이언트는 서버에 있는 HTML데이터 정보를 가져오기만 하면 됐죠. 하지만 단순히 텍스트만 보여주니 밋밋하여 이미지를 추가하게 되었고, 정적인 웹페이지보단 동적인 웹페이지가 세련되 보이게 되어 점차 발전하기 시작합니다.

SOAP 이란?

SOAP은 앞서 말씀드린 초기의 웹통신의 문제점을 보안 하고자 나오게 되었습니다. SOAP는 (Simple Object Access Protocol)로
HTTP, HTTPS, SMTP 등을 통해 XML 기반의 메시지를 컴퓨터 네트워크 상에서 교환하기 위한 통신규약 프로토콜입니다.
restful이 나오기전 기업에서 많이 사용하였다고 합니다. SOAP는 떨어져 있는 서버에게 함수호출이나 객체반환을 통해 원하는 값을 반환 받는 RPC방식입니다. ※RPC(Remote Procedure Call)란 다른 네트워크에 있는 컴퓨터에게 서비스를 요청하는 프로토콜입니다.
아래는 SOAP의 통신구조 입니다.

서버는 WSDL을 UDDI라는 저장소(Service Registry)에 저장합니다.

WSDL은 Web Services Description Language의 약자로, 웹 서비스를 설명하는 XML 기반 언어입니다.
WSDL 문서는 웹 서비스가 어떤 기능을 제공하고, 어떤 메시지 포맷과 프로토콜을 사용하는지를 기술합니다. 또한 웹 서비스의 엔드포인트(Endpoint) 정보를 제공하여 클라이언트가 웹 서비스와 통신할 수 있도록 합니다.

서버쪽(Service Provider)은 이러한 정보를 작성해 UDDI로 올리게 됩니다. (사용자에게 필요한 요구사항을 통보하는것 입니다.)
사용자는 원하는 WSDL을 다운 받고, 양식에 맞게 SOAP를 작성하게 됩니다.

이러한 SOAP는 아래와 같은 단점이 있었고 이를 보안하기 위하여 Restful이 등장하게 됩니다.( 물론 통신방식이 SOAP만 있는것은 아니며 그당시 통상적으로 사용되었던 방식 입니다.)

  • 너무 복잡하다.

  • 해당 문법을 작성하기 위해선 Tool이 필요하다.

  • 무겁고 느리다.

  • 작성하는것 또한 어렵다.

이러한 이유로 2000년대 후반 Open API의 대명사로 REST가 떠오르게 됩니다. REST의 특징은 다음과 같습니다.

  • XML, JSON, RSS 모두 지원한다.

  • HTML의 from method인 GET, POST를 인용한다.

  • 굉장히 직관적이며 GET, POST, PUT, DELETE,PATCH 5가지를 이용해 모든 처리를 완벽하게 할 수 있다.

  • DB를 사용할 때도 REST의 키워드는 매칭이 잘 된다.

  • stateless방식을 사용하며 단순하고 속도가 빠르다.

즉, REST는 기본적인 웹통신을 하고 있는 뜻이 됩니다.

SOAP에 비하면 굉장히 간단하죠?? 서버측에서 요구사항을 통보하고 클라이언트에서는 그 요구사항에 맞춰 하나하나 양식을 적어 서버에 요청하는것과 달리 서버는 클라이언트의 요청이 있을때마다 응답을 합니다. 이렇게 간편한 접근과 손쉬운 사용, 범용성 등의 이점 때문에 많은 웹서버는 RESTful 방식을 사용하고 있습니다. 앞서 말씀드린대로 웹이 http를 제대로 사용하지 못하고 있는 상황을 보고 http의 장점을 최대한 활용할 수 있는 아키텍처로서 rest를 소개했고 이는 http 프로토콜을 의도에 맞게 디자인 하고 있습니다.

api URI 설계

앞서 말씀 드렸듯이 Restful은 HTTP 메서드(GET, POST, PUT, DELETE 등)를 사용하여 클라이언트가 리소스를 생성, 읽기, 업데이트, 삭제(CRUD)할 수 있도록 합니다. 이를 위하여 서버에서는 클라이언트측에서 요청할수 있게 api를 설계하고 api에 맞춰 설계를 진행 해야 됩니다. 지금부터 api설계 방식을 어떻게 설계해야되는지와 HTTP 메서드가 어떤 기능을 하는지 알아보도록 하겠습니다.

api설계에서 중요한것은 리소스 식별입니다. 그렇다면 리소스 식별은 무엇일까요?? 회원을 등록하고 수정하고 조회하는것은 리소스가 아닙니다. 리소스는 행동이 아닌 행동을 하는 주체(회원)을 의미 합니다.
api 설계에서 중요한것은 리소스와 행위를 분리 하는것 입니다.

다시 정리하자면 리소스는 회원, 행위는 조회,등록,삭제,변경 입니다.

아래는 api URI 설계의 예시 입니다.

  • 회원 목록 조회 /members
  • 회원 조회 /members/{id}
  • 회원 등록 /members/{id}
  • 회원 수정 /members/{id}
  • 회원 삭제 /members/{id}

위의 예시를 보면 리소스가 중심이 되어 그에 해당하는 자원을 요청하게끔 api가 있습니다. 하지만 위의 예시를 보면 문제점이 보이시나요?? 회원 조회,등록,수정,삭제의 api구조가 동일한것이 보입니다.
이는 해당 리소스의 행위로 구분할수 있습니다. 이 행위는 http메서드로 표현 할수 있습니다.

http 메서드 종류

GET: 리소스 조회
POST:요청 데이터 처리, 주로 등록에 사용
PUT: 리소스를 대체, 해당 리소스가 없으면 생성
PATCH:리소스 부분 변경
DELETE:리소스 삭제

이외에도 HEAD,OPTIONS,CONNECT,TRACE가 있습니다.

Get

  • 리소스 조회
  • 서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)를 통해서 전달
  • 메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아서 권장하지
    않음

get요청이 이루어지는 과정

위 사진의 흐름을 설명 드리면, 클라이언트에서는 api형식에 맞춰 get요청을 합니다. 그러면 백엔드에서는 id에 해당하는 데이터를 찾아서 json형식으로 응답하게 됩니다. 마지막 사진에서 Content-Type:application/json 은 http 요청과 응답할때 기본값이라 합니다. 응답을 기본적으로 json 형식으로 응답받기 때문입니다. API 서버와 클라이언트 간 데이터 통신에서 널리 사용됩니다. 이 헤더를 사용하면 데이터 형식을 명시함으로써 데이터의 안정성과 일관성을 유지할 수 있습니다.

클라이언트에서 get요청을 할때 body를 담아서 보내지 않지만, body에 세팅해서 보내게 될경우
요청할때 자동으로 쿼리로 변경되어 요청이 변경된다 합니다.

Post

  • 요청 데이터 처리
  • 메시지 바디를 통해 서버로 요청 데이터 전달
  • 서버는 요청 데이터를 처리 & 메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행한다.
  • 주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리에 사용

post 요청흐름도 get과 비슷합니다. 클라이언트측에서 body에 태워서 데이터를 보내면, 서버측에서는 해당하는 리소스를 생성후 등록하게 됩니다. 사진에 있는 /members/100은 리소스 member에 id가 100이라는 신규 데이터를 등록하게 됩니다.

요청 데이터를 어떻게 처리한다는 뜻일까?

POST 메서드는 대상 리소스가 리소스의 고유 한 의미 체계에 따라 요청에 포함 된 표현을 처리하도록 요청합니다. (구글 번역)

위와 같이 구글에서는 정의를 내리고 있는데요! 이해하기 쉽게 예시를 설명 해드리겠습니다.

  • HTML 양식에 입력 된 필드와 같은 데이터 블록을 데이터 처리 프로세스에 제공

    예) HTML FORM에 입력한 정보로 회원 가입, 주문 등에서 사용

  • 게시판, 뉴스 그룹, 메일링 리스트, 블로그 또는 유사한 기사 그룹에 메시지 게시

    예) 게시판 글쓰기, 댓글 달기

Post 정리

  1. 새 리소스 생성(등록)
    • 서버가 아직 식별하지 않은 새 리소스 생성

  2. 요청 데이터 처리
    • 단순히 데이터를 생성하거나, 변경하는 것을 넘어서 프로세스를 처리해야 하는 경우
    • 예) 주문에서 결제완료 -> 배달시작 -> 배달완료 처럼 단순히 값 변경을 넘어 프로세스의 상태가 변경되는 경우
    • POST의 결과로 새로운 리소스가 생성되지 않을 수도 있음
    • 예) POST /orders/{orderId}/start-delivery (컨트롤 URI)

  3. 다른 메서드로 처리하기 애매한 경우
    • 예) JSON으로 조회 데이터를 넘겨야 하는데, GET 메서드를 사용하기 어려운 경우
    애매하면 post메서드를 사용하면 됩니다.

Put

  1. 리소스를 대체

    • 리소스가 있으면 대체

    • 리소스가 없으면 생성

    • 쉽게 이야기해서 덮어버림

  2. 중요! 클라이언트가 리소스를 식별

    • 클라이언트가 리소스 위치를 알고 URI 지정

위의 사진에서 보시는것과 같이 put메서드는 기존 리소스 자체를 없애고 받은 데이터로 덮어 씌워 버립니다. 따라서 강의에서 되도록이면 put매서드를 권장하지 않고 있습니다. 수정이 필요할 경우 patch 매서드를 쓰는게 좋다 합니다.

Patch

  • put과 다르게 리소스를 대체하는것이 아닌 부분 변경하게 해줍니다.

Delete

  • 리소스 제거

http 메서드 속성

  • 안전 하다. (호출해도 리소스를 변경하지 않는다.)
  • 멱등 (한 번 호출하든 두 번 호출하든 100번 호출하든 결과가 똑같다.)
  • 캐시가능 (GET, HEAD, POST, PATCH 캐시가능, But POST, PATCH는 본문 내용까지 캐시 키로 고려해야 하는데, 구현이 쉽지 않음)

클라이언트에서 서버로 데이터 전송

데이터 전달 방식은 크게 두가지로 나뉩니다.

  1. 쿼리 파라미터를 통한 데이터 전송
  • GET
  • 주로 정렬 필터(검색어)

2.메시지 바디를 통한 데이터 전송

  • POST, PUT, PATCH
  • 회원 가입, 상품 주문, 리소스 등록, 리소스 변경

정적 데이터 조회

  • 정적 데이터는 일반적으로 쿼리 파라미터 없이 리소스 경로로 단순하게 조회 가능

동적 데이터 조회

  • 앞서 설명한대로 쿼리 파라미터를 이용하여 조회 한다.

실제 프로젝트에서 구현한 코드 예시

  async function getProducts() {
    const response = await AxiosInstance.get(
      `/products`,

      {
        params: {
          categories: `${categories}`,
          brand: `${brand}`,
          page: 1,
        },
      }
    );

위와 같이 params에 key value 값을 지정해주고 get요청을 하면 자동으로 쿼리에 세팅된다.

참고문헌 김영한님의 모든 개발자를 위한 HTTP 웹 기본 지식

느낀점

restful을 떠올렸을때 CRUD를 하기위해 개발자들끼리 정해놓은 약속 정도로만 생각했는데, 깊이 공부할수록 restful을 이해 하려면 http부터 이해해야 되는점을 알게 되었습니다. 저에게 굉장히 의미있는 시간 이었습니다.

profile
이수연
이전 포스트

백준 11866 자료구조 큐,스택 그리고 js 메서드 shift

다음 포스트

webpack과 babel (zum 과제 직접만들어보기)

0개의 댓글