[Network] REST API - Front-end, Back-end가 개별적으로 일을 할 수 있게된 이유

·2024년 2월 1일
0

Network

목록 보기
3/5
post-thumbnail

REST (Representational State Transfer)

웹 어플리케이션에서 사용되는 통신 아키텍처 스타일로, 클라이언트와 서버 간의 통신 방식을 정의하고 자원과 표현에 의한 상태전달을 진행한다.

자원과 URI (Uniform Resource Identifier)

자원은 웹 어플리케이션에서 관리되는 모든 것을 말한다. 모든 자원은 서버에 존재하며, 이러한 자원을 구별하는 IDURI이다. 클라이언트는 URI를 통해 서버에 요청을 보내며, 서버는 해당 요청에 대한 적절한 응답을 반환한다.

URI vs URL (Uniform Resource Location)

URL 은 인터넷 상 자원의 위치를 말하며, URI는 인터넷 상 자원을 식별하기 위한 문자열의 구성이다. URIURL을 포함하는 개념이다.

자원의 정확한 위치를 포함하는 경우라면 URL, 그렇지 않은 경우는 URI라고 할 수 있다. 정확히는 URLURI에 포함되는 개념이기 때문에, URI이면서 URL에 해당하거나, URI는 맞지만 URL이라 할 수 없는 요소에 대해 예를 들어보자.

예시 1

1. https://www.example.io/index.html
2. https://www.example.io/index

1의 경우, 해당 주소는 index.html에 대한 정확한 파일의 위치를 가리키고 있으므로, URI 이면서 URL에 해당한다 볼 수 있다.

2의 경우에도 index.html 이 렌더링 되는데, 이 경우는 실제 사용된 index.html 을 가리키는 것은 아니다. (웹 서버에서 rewrite 를 통해, index.html 을 반환하도록 한 것이다.) 따라서 URI는 맞지만 URL이라고는 할 수 없다.

예시 2

1. https://www.example.io/category**
2. https://www.example.io/category?page=11&no=204

1의 경우, 해당 주소의 category 데이터들을 가리키므로, URI 이면서 URL에 해당한다 볼 수 있다.

2의 경우에는, 해당 자원의 위치 + 원하는 정보에 대한 쿼리가 포함되었기 때문에, 이 경우 URI는 맞지만 URL은 아니다. 쿼리 외에도 식별자 등을 활용한 경우 (ex:/123) 역시 URL에 해당할 수 없다.

구성요소

자원

URI는 /example/:ex_id 와 같은 형태로 구성된다. 클라이언트는 URI를 통해 서버에 요청을 보내며, 서버는 해당 요청에 대한 적절한 응답을 반환한다.

행위

HTTP 프로토콜의 Method를 사용한다. HTTP MethodCRUD 형태의 GET, POST, PUT, PATCH, DELETE 등을 제공한다.

  • GET : Read의 업무를 수행한다. URI 가진 정보를 검색하기 서버에 요청한다.
  • POST : Create의 업무를 수행한다. 클라이언트에서 서버로 전달하려는 정보를 보낸다.
  • PUT : Update의 업무를 수행한다. 주로 전체의 내용을 갱신하기 위해 사용한다.
  • PATCH : Update의 업무를 수행한다. 주로 일부의 내용을 갱신하기 위해 사용한다.
  • DELETE : Delete의 업무를 수행한다. 서버의 자원을 삭제한다.

표현

클라이언트와 서버가 데이터를 주고 받은 포맷형태로 JSON, XML, TEXT 등이 있다. 일반적으로는 JSONXML을 가장 많이 사용한다.

REST 특징

클라이언트-서버 구조

클라이언트는 서버에게 요청을 보내고 서버는 클라이언트에서 오는 요청에 대해 응답만 보내면 되기 때문에, 개발에 있어서 서버와 클라이언트의 의존성이 줄어들고 개별적인 작업 진행이 가능해졌다.

Stateless, Independency

REST는 무상태성 및 독립성을 갖는다. 통신 시 클라이언트와 서버는 서로의 상태를 인지할 수 없어야 하며, 각 API 요청은 모두 독립적이어야 한다. 예를들어 example.io/aa,example.io/bb 요청이 진행되는 경우, example.io/aa의 요청이 example.io/bb 요청과 연관 되어서는 안된다.

인터페이스 통일

URI 로 지정한 자원에 대한 요청이 통일되어 있으며, HTTP 프로토콜을 따르는 모든 플랫폼에서 인터페이스를 그대로 따라 사용할 수 있기 때문에, 특정 언어나 기술에 종속되지 않은 체 통신 연결을 진행할 수 있다.

또한 통일화된 통신 체계인 만큼, 상대방의 기술적인 부분을 모르더라도 API를 보고도 어떤 자원이 오고 가는지 쉽게 유추할 수 있다.

REST API

REST의 특징을 기반으로 API를 구현하는 것을 말한다.

REST API 가이드

  • URI 및 자원에 대한 행위가 반드시 표현해야한다.
  • 자원에 대한 행위는 반드시 HTTP Method로 표현한다. 또한 행위 자체를 URI에 포함하지 않는다. /getUser, /deleteUser
  • 슬래시로 계층 관계를 표현한다.
  • API 에 대한 명세를 꼭 작성하자.
  • HTTP 응답 상태 코드를 사용한다. 특히 에러의 경우, 어떤 이유에서 나타난 에러인지를 명확히 하기 위해, 에러 메시지를 함께 전달한다.

RESTful API

REST의 설계 규칙을 잘 지킨 APIRESTful API 라고 한다. 즉, REST의 원리를 잘 따르는 API 설계를 “RESTful 하다” 라고 한다.

참고
URI와 URL의 차이점
REST API란?
[Newtork] REST API란

profile
새로운 것에 관심이 많고, 프로젝트 설계 및 최적화를 좋아합니다.

0개의 댓글