Rest와 Rest API에 관하여

REST

 

Rest란, 하이퍼미디어 기반 분산 시스템을 구축하기 위한 아키텍처 스타일이다.

 

한 문장에 전문적인 단어들이 연속해서 들어 있습니다. 하나씩 살펴보자면 아래와 같습니다.

 

하이퍼 미디어 : 웹 페이지에서 텍스트 링크를 클릭하여 새 웹 페이지를 여는 기능, 텍스트 이외의 이미지, 동영상, 그래픽 및 기타 미디어를 클릭하여 비선형 네트워크를 만들수 있도록 하는 기능들을 합친 것

 

분산 시스템 : 공유하는 공동의 목표를 달성하기 위해 여러 개의 개별 컴퓨팅 노드에서 컴퓨팅 리소스를 활용하는 컴퓨터 프로그램의 모음

 

아키텍처 : 시스템 구성 및 동작 원리

 

그렇다면, Rest를 쉽게 표현 하자면,  '각 컴퓨터 소프트웨어들이  자원을 효과적으로 처리하기 위해서 만든 시스템의 동작원리' 라고 생각할 수 있겠습니다.

 

Rest의 구성요소는 아래와 같습니다.

1. 자원 
2. 행위 
3. 표현 

자원을 이름(자원의 표현)으로 구분하여 해당 자원의 상태(정보)를 주고 받는 모든 것을 의미한다.

 

다시말해서, 자원을 HTTP URI를 통해 자원을 구별하고, JSON,XML,TEXT등과 같은 여러 형태로 자원을 표현하고, 그 자원을 HTTP Method(POST,GET,PUT,DELETE)를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것을 의미한다

 

Rest API

 

두 컴퓨터 시스템이 인터넷을 통해 정보를 안전하게 교환하기 위해 사용하는 인터페이스이다.

Rest는 API 작동 방식에 대한 조건을 부과하는 소프트웨어 아키첵처이다.

 

REST가 가지고 있는 아키텍처 스타일은 아래와 같습니다.

 

Rest의 6가지 기본 원칙

 

• 클라이언트/서버 아키텍처 스타일

HTTP라는 프로토콜을 이용해 클라이언트와 서버가 서로 통신하는 클라이언트/서버의 아키텍처 스타일

⇒ 클라이언트가 request를 보내면, 서버가 response를 해준다.

 

클라이언트와 서버는 독립적이어야하며, 클라이언트는 오직 URI 리소스만 알아야한다.

⇒ 이 둘은 독립적으로 개발하거나 대체될 수 있어야한다.

 

장점

단일 컴퓨터 상에서 모든 것을 처리하는 것이 아니기때문에, 클라이언트를 멀티 플랫폼으로 구성 가능하다

또한, 유저 인터페이스는 클라이언트에서 담당하기때문에 서버는 데이터 스토리지로서의 기능만 제공하면 된다.

 

• 스테이트리스 서버

스테이트리스란, 클라이언트의 애플리케이션 상태를 서버에서 관리하지 않는다는 것을 의미한다.

즉, 클라이언트가 보낸 모든 요청에는 서버가 해당 요청을 이해할 수 있는 모든 정보가 포함되어야한다. 그리고, 서버는 이 요청에대해 어느것도 저장하지 않는다.

 

장점 : 스테이트리스한 서버는 애플리케이션 상태를 기억할 필요가 없기 때문에 단순해진다.

단점 : 서버에 송신할 데이터의 양이 많이지고 인증 등 서버에 부하가 걸리는 처리를 반복한다.

 

한계 - Cookie를 사용한 세션 관리는 HTTP를 스테이트풀하게 만드는 대표적인 예이다. → 스테이트리스 서버의 이점을 해친다.

 

• 캐시

캐시 : 리소스의 신선도에 기초해, 한번 가져온 리소스를 클라이언트 쪽에서 돌려쓰는 방식이다.

 

장점 : 서버와 클라이언트의 통신량을 줄여 네트워크 대역의 이용과 처리시간을 축소하고, 더 효율적으로 관리할 수 있다

주의할 점 : 캐시가 오래될 수록 정보의 신뢰성이 떨어진다.

 

• 유니폼 인터페이스

REST는 HTTP 표준에만 따른다면 어떠한 기술이든지 사용할 수 있는 인터페이스 스타일이다.

1. 요청 시 개별 자원을 식별할 수 있어야함, 명확한 리소스 식별자 사용
2. 클라이언트는 원하는 경우 리소스를 수정하거나 삭제하기에 충분한 리소스를 가지고 있어야한다. 따라서, 서버는 리소스를 자세히 설명하는 메타데이터를 전송하여야한다.
3. 서버는 클라이언트가 리소스를 적절하게 사용할 수 있는 방법에 대한 메타데이터가 포함된 명확한 메세지를 전송해야한다.
4. 서버는 클라이언트가 더 많은 리소스를 동적으로 검색할 수 있도록 표현에 하이퍼링크를 넣어 전송한다.

 

• 계층화 시스템

시스템 전체를 계층화한다.

 

클라이언트는 REST API서버만 요청한다. 그러나, 서버는 다중 계층으로 구성되 있어 순수 비즈니스 로직을 수행하는 API 서버와 그 앞단에 사용자 인증, 암호화 등등 여러 계층을 추가하여 구조상의 유연성을 둘 수 있다.

 

• 코드 온 디맨드

프로그램 코드를 서버에서 다운받아 클라이언트에서 실행하는 아키텍처 스타일

ex) javaScript

 

장점 : 클라이언트를 차후에 확장할 수 있다.

단점 : 네트워크 통신에서의 프로토콜 가시성이 저하됨

 

Rest API를 사용하는 이유

• REST는 클라이언트-서버 상호 작용을 최적화하여 확장성을 지원한다. (예를 들어, 무상태와 잘 관리된 캐싱)
• REST API는 완전한 클라이언트-서버 분리를 지원하여 각 부분이 독립적으로 개발될 수 있도록 한다.
• REST API는 API 설계에 영향을 주지 않고 다양한 프로그래밍 언어로 작성할 수 있다.

 

REST API의 작동 순서

1. 클라이언트가 서버에 요청을 전송합니다. 클라이언트가 API 문서에 따라 서버가 이해하는 방식으로 요청 형식을 지정합니다.
2. 서버가 클라이언트를 인증하고 해당 요청을 수행할 수 있는 권한이 클라이언트에 있는지 확인합니다. → 로그인 여부 
3. 서버가 요청을 수신하고 내부적으로 처리합니다.
4. 서버가 클라이언트에 응답을 반환합니다. 응답에는 요청이 성공했는지 여부를 클라이언트에 알려주는 정보가 포함됩니다. 응답에는 클라이언트가 요청한 모든 정보도 포함됩니다.

 

REST API 서버 응답

• 상태 표시줄

요청 성공 또는 실패를 알리는 3자리 상태 코드

• 메세지 본문

응답 본문에는 리소스 표현이 포함

• 헤더

응답에는 응답에 대한 헤더 또는 메타데이터

 

Rest API 디자인

1. URI는 정보의 자원을 명사로 표기해야 한다.

자원을 Collection과 Document로 표현할 수 있는데, Collection을 객체라고 하고

Document를 객체들의 집합이라고 생각!

 

https://example.com/players/soccer

 

   2. 자원에 대한 행위는 HTTP Method(Get, Post, Put, Delete)로 표현한다. - CRUD 함수명을 사용하지 마라!

delete는 자원에 대한 행위 이므로 , HTTP Method(생성,조회,갱신,삭제)로 표현해야한다.

// 회원 삭제
GET /members/delete/1

DELETE /members/3

// 회원 조회
GET /members/1

// 회원 생성
POST /members/2

// 회원 갱신

PUT /members/2

  3. 일관성있게 작성하라

• 계층 관계 표현을 위해 ‘/’ 를 사용해라
• 마지막 문자로 ‘/ ‘ 를 사용하지 마라
• 가독성을 위해 ‘- ‘ (하이폰)을 사용하라
• ‘ _ ‘는 사용하지 마라
• 소문자를 사용하라
• 파일 확장자를 사용하지 마라

 

이상입니다~