[RestAPI] REST API

[RestAPI] REST API

---

프로젝트의 규모가 커짐에 따라 서버의 확장 및 스케일아웃을 하거나 여러 서버를 두고 서버간 통신을 통해 로직을 수행한다.

이번 프로젝트에서 나는 머신러닝 클러스터링을 담당할 서버와 WAS를 분리해서 관리하고자한다.

 

또는 기존 웹 서비스를 다양한 플랫폼에서도 동작하도록 멀티 플랫폼으로 확장한다.

 

즉, 여러 클라이언트가 서버에게 요청을 보내고 응답을 받아야한다.

여기서 클라이언트는 사용자라기 보단 요청을 보내는 쪽이다.

ex) 프론트서버,브라우저,백엔드 서버

서버간 통신에서만 통용되는것은 아니고 모든 기기간 통신에 적용될수있다.

 

서로 다른 서버들은 서버를 구성하는 언어도 기능도 다를것이다.

요청자는 각각의 서버를 잘 모르더라도 어떤 공통의 규칙이 존재하고 이 규칙을 이해한다면 각 서버를 좀더 쉽게 이용할수있다면 편리할 것이다.

 

이 어떠한 규칙을 REST 라고 하며

 

이 REST를 잘 지켜서 RESTFUL하게 개발된 서버를 RESTAPI라고 부른다.

 

즉, 서버의 개발에 있어서 RestAPI는 필수적인 요소이다.

RestAPI 말고도 Graphql이라는 형식도 있지만 그건 추후에 다루도록 하겠다.

 

용어사전

Interface: 광범위한 개념, 어떤 기능을 활용하기 위한 제어시스템

인터페이스는 서로 다른 두 개의 시스템, 장치 사이에서 정보나 신호를 주고받는 경우의 접점이나 경계면이다.

하드웨어 인터페이스: 하드웨어 간의 상호작용

소프트웨어 인터페이스: 소프트웨어 간의 상호작용

사용자 인터페이스: 사람과 기계간의 상호작용

API(Application Programming Interface): 응용프로그램에서 제공하는 기능을 쉽게 제어 및 사용 할수있게 만든 인터페이스

사용하고자하는 프로그램의 내부를 몰라도 쉽게 제어가 가능하다

API는 리모컨과 점원처럼 애플리케이션과 운영체제 그리고 애플리케이션과 프로그래밍 언어가 제공하는 기능 사이의 '상호 작용'을 돕는다

 

RestAPI

개요

인터넷상에서 기계들은 HTTP를 통해 통신을 주고받는다.

request & response

http message body에 데이터를 담아 주고받는다. ex) json , xml 데이터 포멧 이용

 

이때 웹에서 일어나는 모든 기계간 통신에 공통적인 규칙을 정해둔다면 더 명확하고 확실하게 상호작용 할수있을것이다.

먼저 Rest란?

인터넷상에서 요청자는 HTTP와 URI를 이용해, 다른 컴퓨터의 리소스에 접근해 데이터를 요청하고 해당 컴퓨터로부터 응답을 받는다.

구글 서버의 게시물 post 리소스에 접근

 

이때 해당 기기 리소스의 위치는 HTTP URI를 통해 명시된다.

이 URI를 통해 접근한 리소스의 데이터를 CRUD하여 처리할수있어야하는데 이때 HTTP Method를 적극 활용하여 처리하도록 되어있다.

이런 일련의 약속을 Rest라고 한다.

 

즉 Rest란

1. HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고,
2. HTTP Method(POST, GET, PUT, DELETE)를 통해
3. 해당 자원(URI)에 대한 CRUD Operation을 적용하는 것을 의미한다.

Create : 데이터 생성(POST)
Read : 데이터 조회(GET)
Update : 데이터 수정(PUT)
Delete : 데이터 삭제(DELETE)

 

REST의 특징

Server-Client(서버-클라이언트 구조)

자원이 있는 쪽이 Server, 자원을 요청하는 쪽이 Client가 된다.

REST Server:API를 제공하고 비즈니스 로직 처리 및 저장을 책임진다.

Client: 사용자 인증이나 context(세션, 로그인 정보) 등을 직접 관리하고 책임진다.

 

서로 간 의존성이 줄어든다.

 

Stateless(무상태)

HTTP 프로토콜은 Stateless Protocol이므로 REST 역시 무상태성을 갖는다.

Server는 각각의 요청을 완전히 별개의 것으로 인식하고 처리한다.

 

Cacheable(캐시 처리 가능)

웹 표준 HTTP 프로토콜을 그대로 사용하므로 웹에서 사용하는 기존의 인프라를 그대로 활용할 수 있다.

캐시 사용을 통해 응답시간이 빨라지고 REST Server 트랜잭션이 발생하지 않기 때문에 전체 응답시간, 성능, 서버의 자원 이용률을 향상시킬 수 있다.

 

Layered System(계층화)

Client는 REST API Server만 호출한다.

REST Server는 다중 계층으로 구성될 수 있다.

순수 비즈니스 로직, 암호화, 보안, 인증을 계층화 하여 유연하게 개발이 가능하다.

 

Uniform Interface(인터페이스 일관성)

URI로 지정한 Resource에 대한 조작을 통일되고 한정적인 인터페이스로 수행한다.

HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다.

 

*REST가 필요한 이유

 

다양한 기기의 등장과 어플리케이션 분산과 통합에 따라 각 기기간 종류에 상관없이 통신할수있어야한다.

다양한 기기가 서비스 리소스에 대한 공통된 규칙으로 서로 통신하도록 하기위해 REST가 필요하다.

 

그럼 RestAPI란?

 

REST의 원리를 따라 RESTFUL하게 개발된 서비스 API

• 많은 업체들이 Rest API를 제공한다.

OpenAPI 등

즉 Rest API란

 

REST원리에 따라 URI로 리소스 구조를 표현하고 + Http Method를 이용해 상호작용하도록 설계하는 API라는 말이다.

 

예시를 보자.

www.moviestar.com

이와 같은 영화정보를 제공해주는 서버가 있다.

이 서버에 영화 목록 리소스에 접근하려면

[GET] www.moviestar.com/movies

GET 방식으로 해당 URI에 request한다.

만약 영화를 등록하고싶다면

[POST] www.moviestar.com/movies

POST 방식으로 해당 URI에 request한다.

즉 같은 URI라도 HTTP method에 따라 하는 동작이 달라진다.

 Create : 데이터 생성(POST)
 Read : 데이터 조회(GET)
 Update : 데이터 수정(PUT)
 Delete : 데이터 삭제(DELETE)

다음과 같은 4가지 method를 사용하여 crud를 실현한다.

URI도 설계하는 규칙이 존재한다.

 

동사를 사용하지말것

www.moviestar.com/getmovies
www.moviestar.com/postmovies

동사를 사용하게 되면 이처럼 동작에 따라 많은 URI가 생성되어야 하고 복잡해진다.

엘리먼트는 ID로 구분한다.

[GET] www.moviestar.com/movies/1/actors/2

위 요청은 영화목록의 1번째 영화의 2번째 배우 정보 열람을 요청한다는것을 알수있다.

URI 마지막 문자로 슬래시(/)를 포함하지 않는다.

 

하이픈(-)은 URI가독성을 높이는데 사용

불가피하게 긴 URI경로를 사용하게 된다면 하이픈을 사용해 가독성을 높일 수 있다.

 

URI 경로에는 소문자가 적합하다.

 

파일 확장자는 URI에 포함시키지 않는다.

http://restapi.example.com/members/soccer/345/photo.jpg (X)

Accept header를 사용할것

 

REST원칙을 잘 지켜 RESTFUL하게 API를 설계해서 REST API를 잘 제공한다면

1. 같은 URI로도 HTTP method를 다르게하여 다양한 동작을 실행시킬수있다.
2. 요청 URI+method 만으로도 어떤 요청인지 직관적으로 파악할수있다.
3. 정형화된 원칙으로 설계했기 때문에 다른 팀원들과 공유하는 경우에도 이해하기 쉽다.

 

Reference

---

노마드코더

생활코딩