_RESTful API_

백엔드 코드를 구현할 때 RESTful API 라는 개념이 자주 등장한다. 과연 이게 무엇일까

API란?

우선 API가 무엇인지 이해를 해야 할 것 같다.

API란 Application Programming Interface의 약자로, 다른 소프트웨어 시스템과 통신하기 위해 따라야 하는 규칙이다.

즉 데이터와 기능의 집합을 제공하여 프로그램 간 상호 작용을 통해, 정보를 교환 가능하도록 하는 것

HTTP URI

리소스를 고유하게 식별하는 것, URL과 보통 혼용되고 있다.

- ex. www.example.com/font/2 에서 2가 리소스

REST 란?

목표

1. 컴포넌트 간 확장성을 가진 상호 연동성 확보
2. 범용 인터페이스
3. 각 컴포넌트들의 독립적인 배포
4. 지연 감소, 보안 강화, 레거시 시스템을 인캡슐레이션 하는 중간 컴포넌트로의 역할

인캡슐레이션: 데이터에 헤더가 추가되는 과정. 즉, 한 프로그램에서 다른 프로그램으로 데이터를 전송할 때 데이터를 패키지화 하는 과정

개념

REST는 Representational State Transfer(REST)의 약자로, API 작동 방식에 대한 조건을 부과하는 소프트웨어 아키텍처 스타일이다.

네트워크 상에서 Client와 Server 사이의 통신 방신 중 하나로, 자원을 이름으로 구분하여 해당 자원의 상태를 주고 받는 모든 것을 의미하는 것이다.

HTTP Method (POST, GET, PUT, DELETE)를 통해 자원에 대한 CRUD Operation을 적용하는 것을 의미한다.

• 자원: 해당 소프트웨어가 관리하는 모든 것
  • 문서, 그림, 데이터, 소프트웨어 자체 등...
• 자원의 이름(자원의 표현)
  • 학생 정보가 자원일 때, 'student'를 자원의 표현으로 정한다.
• 상태 전달
  • 데이터가 요청되는 시점의 자원의 상태를 전달
  • 일반적으로 JSON 혹은 XML 포맷을 통해 주고받는다.

CRUD Operation

• Create: 생성 (POST)
• Read: 조회 (GET)
• Update: 수정 (PUT)
• Delete: 삭제 (DELETE)
• HEAD: header 정보 조회 (HEAD)

REST 특징

• 클라이언트 / 서버 구조
  • 클라이언트는 유저 관련 처리, 서버는 REST API 제공으로 역할 분리
  • 때문에 서버와 클라이언트 간 의존성이 줄어든다.
• REST Server: API 제공, 비즈니스 로직 처리 및 저장
  • Client: 사용자 인증 / Context(세션, 로그인 정보) 등을 직접 관리 및 책임
• 무상태성 (Stateless)
  • 서버에서 어떤 작업을 하기 위해 상태 정보를 기억할 필요가 없고, 들어온 요청에 대해 처리만 해주면 된다.
• 캐시 처리 가능 (Cacheable)
• HTTP 웹 표준을 사용하기에, 기존 웹 인프라를 그대로 사용
• 대량의 요청을 효율적으로 처리. 응답시간이 빨라지고 REST Server 트랜잭션이 발생하지 않기 때문에 전체 응답시간, 성능, 서버의 자원 이용률을 향상
• 자체 표현 구조 (Self- Descriptiveness)
  • JSON을 이용한 메세지 포맷을 이용해 요청에 대한 이해가 쉽다
• 계층화
  • 클라이언트와 서버가 분리되어 있기 때문에, 프록시 서버 / 암호화 계층 등 중간매체를 사용할 수 있음
• 유니폼 인터페이스
  • HTTP 표준에만 따른다면 모든 플랫폼에서 사용 가능하며, 리소스 조작이 통일되기 때문에 특정 언어나 기술에 종속되지 않는다

RESTful API란?

REST 기반으로 API를 구현한 것을 RESTful 웹 서비스라고 지칭한다.

즉 REST 하게 자원으로 구분을 잘 한 API라는 의미

확장성과 재사용성을 높여 유지보수 및 운용의 편리성을 확보할 수 있다.

개인적으로 정의하자면, 통신의 표준화라고 생각한다.

규칙

1. 슬레시(/)는 계층 관계를 나타내는데 사용한다.
2. URI 마지막 문자로 슬레시(/)는 사용하지 않는다.
3. 하이픈(-)은 URI 가독성을 높이는데 사용한다.
4. 밑줄 (_)은 URI에 사용하지 않는다.
5. URI는 최대한 소문자를 사용한다.
6. 파일 확장자는 URI에 포함하지 않는다.

참고 링크

- REST, REST API, RESTful 특징 (https://hahahoho5915.tistory.com/54)

gRPC란 무엇일까? 이를 알기 위해선 RPC를 먼저 알아봐야 한다.

RPC (Remote Procedure Call)

_RPC 메커니즘_

RPC는 API를 구축하는 접근 방식이다.

클라이언트 - 서버 간 상호 작용 방식으로, 원격 제어를 위한 코딩 없이 다른 주소 공간에서 함수나 프로시저를 실행할 수 있게 하는 프로세스간 통신 기술이다. 즉, 로컬 위치 혹은 원격 위치에 있는 기능을 수행할 수 있게 하는 것이다.

정리하자면, 원격으로 특정 함수나 프로시져를 호출할 수 있게 하는 것이다.

• 교환이 간단하다.
• 내용이 가볍다.
• 따라서 프로그래밍 부담이 적고 속도가 빠르다.

방법

• 양쪽의 인터페이스 규약을 IDL등의 언어로 정의
• 해당 프로그래밍 언어가 부를 수 있는 형태의 코드로 생성

함수 - 프로시져

• 함수: 입력값(input)에 따른 출력값(output)을 내보내는 것.
• 프로시져: __명령 단위가 수행하는 절차__에 집중한 개념. 따라서 출력값은 없을 수도 있으며, 함수보다 큰 단위의 실행에 사용된다.

IDL (Interface Definition Language)

RPC는 IDL을 이용한다. IDL이란 인터페이스 정의 언어로, 어느 한 언어게 국한되지 않게 인터페이스를 표현하는 방법

• 서버 호출 규약 정의
• 함수명, 인자, 반환값에 대한 데이터 타입 지정

gRPC (Google Remote Procedure Call)

gRPC는 구글에서 개발한 RPC 기반의 통신 방식이다.

_gRPC 메커니즘_

왼쪽 service가 서버, 오른쪽 client가 클라이언트이다.

그리고 각각 프로그래밍 언어가 적혀있는 것은 서로 다른 언어들끼리도 통신할 수 있다는 것을 예시로 든 것이다.

특징

• JSON 혹은 XML이 아닌 프로토콜 버퍼 기반의 메시지를 바이너리 형식으로 직렬화 통신
• 프로토콜 버퍼로 원하는 메시지 타입을 미리 정의
• HTTP/2를 사용하기 때문에, 요청-응답을 넘어 스트리밍도 지원

프로토버퍼 (Proto Buffer)

gRPC에서 통신하기 위해 서비스 인터페이스를 정의하는 방법.

• 프로토 파일로 정의된 메세지 포맷들을 이용하여 직렬화(Serialize)
• 프로토 파일을 토대로 받은 메세지를 역직렬화

RPC vs REST API

• REST API는 JSON 혹은 XML 형식을 사용하여 통신하기에 크기가 크고 따라서 상대적으로 느리다.
• REST API 서버는 클라이언트와 **엔드포인트(End Point)**를 공유한다. 반면 gRPC는 클라이언트와 __함수__를 공유한다.
• REST API는 HTTP 상태 코드로 표시하는 반면, gRPC는 에러 코드를 사용한다.

장점

• 속도가 빠름
• 엄격한 타입 검사
• 이중 스트리밍

단점

• 엄격한 타입 검사 때문에 주기적으로 변경하고 업데이트하는 것이 부담이 될 수도 있다.
• 부족한 생태계: 비교적 최근 기술이기 때문에 환경이 국한되어 있고 자료가 부족하다.