RESTful API , SOAP

송철진·2022년 11월 10일

요약

REST API : 상태(State)를 전달(Transfer)하는 것을 나타내는(Representation) 방법. 자원을 이름(자원의 표현)으로 구분하여 해당 자원의 상태(정보)를 주고 받는 것.

REST는 API를 설계할 URI 자원으로 한정된, 통일되고 일관적인 인터페이스(uniform interface)를 구현.

URI는 동사를 제외한, 명사로 구성.

Resource에 대한 행위를 HTTP method (GET, POST, PUT, DELETE)만으로 표현.

Resource 사이에 연관 관계 및 계층 관계가 있는 경우 slash(/) 를 사용

응답 Response 의 status code 기본 규칙을 따른다.

REST하게 설계된 API는 client-server 분리와 함께 발달 했으며,
이로 인해 client-server 개별 부분의 발전에 다른 부분이 영향을 주지 않는다는 장점이 생겼다.

HTTP 통신 상태에 대한 정보를 따로 저장하거나 관리 하지 않는 것이 (state + less) REST의 특징이다. 이러한 특징은 cache를 발달시켰다. 특징요청에 관한 응답을 따로 저장함으로써 추후에 재사용이 가능해진다.

1. REST API 란?

REST API : REST하게 API를 서술하는 방법

Representational State Transfer (REST)

상태(State)를 전달(Transfer)하는 것을 나타내는(Representation) 방법

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

통신한다 = 특정 자원(데이터)을 어떤 방식으로 전달한다 라면
이를 표현하는 방식을 통일하여, 개발자들 사이에서 의사소통을 원활히 하자!

요청은 "무엇을 어떻게"의 방법이다.

'무엇을' = 특정 데이터 resource, URI (Uniform Resource Indentifier)로 표현.
'어떻게 하겠다' = 동사, http method로 표현.

(https://velog.io/@scroll0908/URI-URL-URN)

REST API의 역사

HTTP 개념 설립의 주요 저자 중 한 사람인 로이 필딩(Roy Thomas Fielding)은 당시 웹(HTTP) 설계의 우수성에 비해 널리 사용되지 못하는 현상을 안타까워함. 좋은 설계로 웹의 장점을 최대한 활용할 수 있어야 한다는 필요를 느끼고 웹 아키텍처인 REST를 설계하여 발표.
1996년부터 1999년까지 HTTP 1.0의 기존 디자인에 기반을 둔 HTTP 1.1와 병행하여 REST 구조의 스타일을 개발,
2000년도에 박사 학위 논문으로 REST 발표.

REST API의 장점

Self-descriptiveness
RESTful API는 그 자체만으로도 API의 목적이 쉽게 이해된다

요청	RESTful API
user들의 정보를 get 하고자 함	[GET] http://localhost:8000/users
starbucks에서 1번 beverages의 정보를 get 하고자 함	[GET] http://starbucks.com/beverages/1
starbucks에서 2번 beverage를 주문하고자 함	[POST] http://starbucks.com/order - body {beverage:2}

문서나 주석이 없이도 해석이 쉽다.

2. SOAP 란?

SOAP(Simple Object Access Protocl)
XML 기반의 메시지 전송 프로토콜.

REST와는 보안이나 메세지 전송 방식등이 다르다.
보편적인 웹 서비스보다는 기업 또는 특정 조직 내부에서 사용하기 적합하다.

특징

원격 프로시저 호출 패턴 (참고자료: [RabbitMQ] 원격 프로시저 호출 (RPC))
플랫폼에 종속되지 않아 이 기종 간 통신 가능
헤더와 바디를 가지며 헤더에는 메타 정보, 바디에는 실제 정보가 들어가 있음
규약, 에러 처리, 분산 처리에 대한 옵션이 내장되어 있음

3. REST와 SOAP의 차이점

전세계에서 가장 보편화되어 사용되고 있는 웹 API 패러다임

SOAP은 프로토콜이고, REST는 api 설계 스타일이기 때문에,
두 개념을 독립적으로도 이해해야 한다.

	REST	SOAP
정의	API 설계 스타일	프로토콜
작성 방식	리소스(데이터) 중심으로 묘사	행위, 기능 중심으로 서술
전송 데이터	⭐️여러가지 형태의 데이터 (html, json, text)	XML 데이터(고정)
캐시 사용	⭐️가능, 효율적	불가, 비효율적
ACID특성	없음	자체 기준 있음

⭐️보편적인 웹 서비스에서 SOAP이 아닌 HTTP를 통한 REST를 사용하는 이유

4. RESTful API 설계 원칙 5+1

프로그램의 원활한 유지보수와, 개발자들 사이에서의 커뮤니케이션을 원활히 돕도록 만들어진 규칙

4-1. Uniform Interface

REST는 API를 설계할 때 자원을 중심으로 만드는 것이 원칙이다.
따라서 URI 자원으로 한정된 일관적인 인터페이스 (uniform interface)를 구현하는 것으로 자원 조작을 통일하는 것이 좋다.

HTTP를 구성하는 URL, HTTP method, Status Code를 통해 인터페이스를 구현한다.

URI는 동사를 제외한, 명사로 구성한다.

어떠한 요청을 진행할 대상(URI), 자원을 정확하게 지칭하는 명사

BAD	GOOD
[GET] /find/users/1	[GET] /users/1
[POST] /insert/user/2	[POST] /users/2

Resource에 대한 행위를 HTTP method (GET, POST, PUT, DELETE)만으로 표현한다.

BAD	GOOD
[DELETE] /delete/users/1	[DELETE] /users/1
[POST] /post/products	[POST] /products

Resource 간 연관, 계층 관계는 slash(/) 를 사용한다.
ex) [GET] /users/{user_id}/profile
URI 마지막 문자로 /를 포함하지 않는다.

BAD	GOOD
[GET] /users/portfolios/	[GET] /users/portfolios

URI가 길어지는 경우 -로 가독성을 높인다.

BAD	GOOD
[GET] /users/1/ordered_items	[GET] /users/1/ordered-items

파일 확장자는 URI에 포함시키지 않는다.
payload에 포함되는 파일의 확장자는 headers에 포함된다.

BAD	GOOD
[GET] /users/1/profile-photo.jpg	[GET] /users/1/profile-photo

응답 Response 의 status code의 기본적인 규칙을 따른다.

4-2. Client - Server

데이터를 저장하는 데이터 스토리지 부분과, 이를 활용하고 서비스를 구동하는 유저 인터페이스를 분리하는 것.

서버는 API를 제공하는 역할만 수행,
클라이언트는 사용자 인증이나 컨텍스트(세션, 로그인 정보등)를 직접 관리.

클라이언트(프론트엔드)와 서버(백엔드)에서 개발해야할 내용이 명확해졌기 때문에 서로의 의존성이 줄어들었다.
👉 각자 신경써야 하는 개발 분야가 달라졌음(관심사의 분리), 독립적인 개발이 가능.
👉 개별 부분의 발전에 있어 다른 부분이 영향을 주지 않는다는 장점이 생김.

4-3. Stateless

상태에 대한 정보를 따로 저장하거나 관리 하지 않는 것(state + less)

API서버는 들어오는 요청만을 단순히 처리,
요청에 대한 결과를 서버에 따로 저장하지 않기 때문에,
이미 로그인을 했는지, 이미 주문을 했는지 서버는 알지 못한다.
👉 서비스의 자유도가 높아지고,
👉 서비스 구현이 단순해짐.(불필요 정보 관리X)

코드의 가시성과 안정성 확보,
더 간편하게 확장될 수 있다.
서버가 세션 정보, 쿠키 정보 또한 별도로 저장하거나 관리하지 않기 때문에 클라이언트에서 상태 정보를 항상 전송. 👉 통신 비용이 높아짐.

4-4. Cacheable

Stateless에서 통신 비용이 높아짐을 해결하기 위한 정책
요청에 관한 응답을 따로 저장하여 추후에 재사용이 가능.

클라이언트-서버의 상호 작용을 제거 👉 성능 향상, 보다 확장성을 보장
추가적인 기능을 생성하는 것이 아닌 기존 웹 표준을 사용하기 때문에,
HTTP가 기본적으로 가지고 있는 캐시 정책을 사용할 수 있다.

요청에 대한 응답을 매번 갱신하는 것이 아니기 때문에,
캐시를 이용하여 데이터를 보여줄 경우 서버측에서 업데이트된 데이터가 반영되지 않고, 캐시된 데이터를 보여줄 경우 신뢰성을 감소시킬 우려가 있다.

예)

첫번재 요청 GET /v2/tasks/2
Reponse 200 OK
Last-Modified: Sun, 03 Apr 2016 16:09:23 GMT
두번째 요청 GET /v2/tasks/2
If-Modified-Since: Sun, 03 Apr 2016 16:09:23 GMT
Reponse 304 Not Modified
기존의 데이터를 그대로 사용한다(이건 구현에 따라서 달라질 수 있다)

4-5. Layered System

여러 기능이 혼재된 인터넷 규모의 요구 사항을 향상시키기 위해서 레이어드 시스템을 지키며 설계되어 있다.

복잡한 여러 기능을 계층화 시켜서 한 기능씩 순차적으로 진행하는 것

레이어가 여러 층으로 구성되어 있어, 특정 기능이 진행되는 동안은 해당 레이어 너머의 시스템을 확인할 수 없게 하여, 시스템 복잡성을 낮출 수 있다.
레이어 중간에 공유 중개자를 두어 로드밸런싱 및 캐시 정책을 도입할 수 있게 해준다.
계층별로 독립적인 기능을 수행하기 때문에, 특정 기능이 오래되어 (레거시 서비스) 교체가 필요할 때에도 새로운 서비스를 완전히 격리할 수 있다.
계층적으로 일이 처리되다 보면 데이터 처리에 과부하가 더해지므로 응답이 늦어질 수 있다.

4-6. Code on Demand

서버가 네트워크를 통해 클라이언트에 전달한 javascript 등과 같은 프로그램들은 그 자체로 실행이 될 수 있어야 한다. 서버로부터 기능을 내려받아 클라이언트에서 바로 실행할 수 있어야 한다
👉 사전에 구현에 필요한 기능의 수를 줄여 클라이언트를 단순화할 수 있다.

code on demand 원칙은 client에 보내는 데이터를 바로 실행 가능한 코드의 형태도 보내어 client가 곧바로 실행하는 것.