[CS] REST API, REST-ful이란?

REST(REpresentational State Transfer)란?

HTTP 통신에서 어떤 자원에 대한 CRUD 요청을 Resource와 Method로 표현하여 특정한 형태로 전달하는 방식

즉, REST란 어떤 자원에 대해 CRUD연산을 수행하기 위해 URI(Resource)로 요청을 보내는 것으로, POST / GET / PUT / DELETE / PATCH 등의 방식(Method)를 사용하여 요청을 보내며 요청을 위한 자원은 특정한 형태(Representation of Resource)으로 표현된다.

이러한 REST기반의 API를 웹으로 구현한 것이 REST API이다.

 

REST의 구성요소

• 자원 (Resource) - URI
  서버는 고유한 ID를 가지는 Resource를 가지고 있으며, 클라이언트는 이러한 Resource에 요청을 보낸다. 이러한 Resource는 URI에 해당한다.
  
  
• 행위(Verb) - Method
  CRUD 연산 중에서 처리를 위한 연산에 맞는 Method를 사용하여 서버에 요청을 보내야 한다.
  서버에 요청을 보내기 위한 방식으로 GET, POST, PUT, PATCH, DELETE 등이 있다.
  
  • Create : 데이터 생성(POST)
  • Read : 데이터 조회(GET)
  • Update : 데이터 수정(PUT / PATCH)
  • Delete : 데이터 삭제(DELETE)
• 내용(Representation of Resource) - 최근에는 Key, Value를 활용하는 json을 주로 사용한다.
  클라이언트와 서버가 데이터를 주고받는 형태로 json, xml, text, rss 등이 있다.

 

❓URI 과 URL의 차이점은?
URL은 Uniform Resource Locator로 인터넷 상 자원의 위치를 의미한다. 자원의 위치라는 것은 결국 어떤 파일의 위치를 의미하는 것이다. 반면에 URI는 Uniform Resource Identifier로 인터넷 상의 자원을 식별하기 위한 문자열의 구성으로, URI는 URL을 포함하게 된다. 그러므로 URI가 보다 포괄적인 범위라고 할 수 있다.

 

REST의 특징

1. Uniform Interface(일관된 인터페이스)

Uniform Interface는 Http 표준에만 따른다면 모든 플랫폼에서 사용이 가능하며, URI로 지정한 리소스에 대한 조작을 가능하게 하는 아키텍쳐 스타일을 말한다

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

즉, 특정 언어나 기술에 종속되지 않는다.

 

2. Stateless(무상태성)

보통 클리이언트-서버 간 통신에는 상태가 존재하지 않으며 모든 요청은 필요한 모든 정보를 담고 있어야 한다.

따라서 이러한 특성으로 인해 요청 하나만 보더라도 바로 흐름을 알 수 있을 뿐 아니라 에러 발생시 이를 복원하기가 쉬우며 상태를 굳이 저장하지 않기 때문에 규모 측면에서 확장성 또한 개선된다

 

결론적으로,  REST API는 서버에서 어떤 작업을 하기 위해 상태 정보를 기억할 필요가 없고 들어온 요청에 대해 처리만 해주면 되기 때문에 구현이 쉽고 단순해진다.

 

무상태성에 대한 이해가 조금 어려울 수 있다. 사실 내가 그렇다   이해를 돕기 위해 좋은 예시가 있어서 한번 가져와보았다.

보통 물건을 구매하면 점원 한 명만 통하므로 컨텍스트를 계속 알고 있어 바로 소통이 된다

하지만 점원 A에게 물어보던 내용을 점원 B, C에게 이어서 물어본다면 둘은 당황스러울 것이다. B와 C는 컨텍스트를 모르기 때문이다.

정리하자면, 첫 번째 케이스는 클라이언트가 노트북을 구매하고 싶다는 상태를 알고 있다. 그 상태를 알고 있기 때문에 결제 수단을 물어본다. 최종적으로 노트북 산다, 2개를 산다, 신용카드로 구매한다는 상태를 유지하게 된다.

 

하지만 두 번째 케이스의 경우, 점원이 고객의 상태를 유지하지 않는다. 따라서 고객은 물어볼 때마다 매번 무엇을 몇개, 어떤 결제 수단을 사용할지 말해줘야 한다.

무상태는 점원이 바뀌더라도 고객이 매번 명확하게 말해주기 때문에 올바른 결과를 받을 수 있다. 따라서 무상태로 설계하면 무한적 확장할 수 있는 가능성이 생긴다.

 

 

+

Stateful service와 stateless service의 차이를 조금더 딥하게 알고 싶어 정리한다.

 

https://5equal0.tistory.com/entry/StatefulStateless-Stateful-vs-Stateless-%EC%84%9C%EB%B9%84%EC%8A%A4%EC%99%80-HTTP-%EB%B0%8F-REST

[Stateful/Stateless] Stateful vs. Stateless 서비스와 HTTP 및 REST

 

Stateful 구조는 Server와 Client간 세션 상태(state)에 기반하여 Client에게 응답을 보낸다. 이를 위해 세션 '상태'를 포함한 Client와의 세션 정보를 server에 저장하게 된다.

 

위 블로그에서 작성한 예시는 다음과 같다.

대표적인 Stateful 구조를 따르는 프로토콜로 TCP가 있습니다. 
TCP의 3-way handshaking 과정을 생각해봅시다.
Server와 Client는 3-way handshaking 과정에서 SYN과 SYNACK을 주고 받으며,
양단간 세션 '상태'를 established한 '상태'로 만듭니다.
세션 '상태'가  established가 되면 client와 server는 데이터를 주고 받을 수 있습니다.
이렇게 TCP는 세션 '상태'에 따라 Server의 응답이 달라지는 Stateful 프로토콜입니다.
 
 
TCP의 데이터 전송과정도 확인해 봅시다. 
server는 client로부터 송신된 패킷헤더를 파싱하여
앞으로 수신해야할 데이터의 크기(window), sequence 번호 등을 저장합니다. 
그리고 해당 크기의 데이터가 모두 수신 될 때까지 client와의 세션을 유지합니다. 
이 과정에서 server는 앞으로 수신할 데이터의 크기, sequence 번호 등과 같이 client와의 세션 정보를 저장하게 됩니다.

 

정리하자면

 

client <---데이터---> server 

요런식으로 client와 서버는 데이터를 주고받고, 세션 상태에 따라 server의 응답이 달라진다.

데이터 전송과정에서 server는 수신해야할 client의 정보들을 저장하는데 해당 데이터가 모두 수신될 때까지 client와의 세션을 계속 유지한다. 

 

그러나 이런 방식은 한 서버에 정보를 저장하기 때문에 다른 서버는 해당 정보를 가지고 있지 않다.

 

반면에 Stateless 구조는 server의 응답이 client와의 세션 상태와 독립적이다. 이 구조에서 server는 단순히 요청이 오면 응답을 보내는 역할만 수행하고, 세션 관리는 client가 해야한다.

 

client가 세션관리를 하므로 server는 이러한 정보를 저장하지 않는다. 대신 필요에 따라 외부 DB에 저장해서 관리할 수 있다.

 

Stateless에 대한 예시는 다음과 같다.

대표적인 Stateless 프로토콜로는 UDP와 HTTP 등이 있습니다. 
여기서는 UDP를 예로 들어 보겠습니다. 
아시다시피, UDP는 TCP와 달리 handshaking 과정을 통해 연결 세션을 인증하는 절차를 수행하지 않습니다. 
세션 상태에 관계 없이 단순히 데이터그램을 source에서 destination 쪽으로 전송합니다.
client가 송신하려 했던 모든 데이터가 server쪽에 수신 되었는지 확인하지 않습니다. 
따라서 server쪽은 client와의 세션 정보를 전혀 저장하지 않습니다. 

TCP vs. UDP

stateless 구조는 client와의 세션 상태에 관계없이 요청에 대한 응답만을 수행한다. 즉, client와 server가 계속 연결을 유지하지 않아도 된다. 

 

이러한 방식은 외부 DB를 통해 client의 정보에 접근이 가능하기 때문에 서로 다른 서버에서도 접근이 가능하다.

 

 

 

3. Cacheable(캐시 처리 가능)

HTTP라는 기존 웹표준을 사용하는 REST의 특징 덕분에 기본 웹에서 사용하는 인프라를 그대로 사용 가능하다.

대량의 요청을 효율적으로 처리하기 위해 캐시가 요구된다.

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

 

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

클라이언트는 유저와 관련된 처리를, 서버는 REST API를 제공함으로써 각각의 역할이 확실하게 구분되고 일괄적인 인터페이스로 분리되어 작동할 수 있게 한다

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

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

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

 

5. Self-Descriptiveness(자체 표현)

JSON을 이용한 메시지 포멧을 이용하여 직관적으로 이해할 수 있고 REST API 메시지만으로 그 요청이 어떤 행위를 하는지 알 수 있다.

 

6. Layered System(계층 구조)

클라이언트와 서버가 분리되어 있기 때문에 중간에 프록시 서버, 암호화 계층 등 중간매체를 사용할 수 있어 자유도가 높다

 

REST API의 장단점

장점

• HTTP 프로토콜의 인프라를 그대로 사용하므로 REST API 사용을 위한 별도의 인프라를 구출할 필요가 없다.
• HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다.
• Hypermedia API의 기본을 충실히 지키면서 범용성을 보장한다.
• REST API 메시지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악할 수 있다.
• 여러 가지 서비스 디자인에서 생길 수 있는 문제를 최소화한다.
• 서버와 클라이언트의 역할을 명확하게 분리한다.

 

단점

• 표준이 자체가 존재하지 않아 정의가 필요하다.
• 사용할 수 있는 메소드가 4가지(POST, GET, PUT, DELETE)밖에 없다. 따라서 HTTP Method 형태가 제한적이다.
• 브라우저를 통해 테스트할 일이 많은 서비스라면 쉽게 고칠 수 있는 URL보다 Header 정보의 값을 처리해야 하므로 전문성이 요구된다.

 

 

REST API의 규칙

REST API를 올바르게 설계하기 위해서는 지켜야할 몇가지 규칙이 있다

 

중심규칙

URI는 정보의 자원을 표현해야한다

자원에 대한 행위는 HTTP Method (GET, POST, PUT, DELETE 등)으로 표현한다.

 

세부규칙

1. URI는 명사를 사용한다.
2. 슬래시( / )로 계층 관계를 표현한다.
3. URI의 마지막에는 슬래시를 붙이지 않는다.
4. URI 경로는 소문자로만 구성한다.
5. 가독성이 떨어지는 경우 하이픈을 사용한다.
6. 밑줄 ( _ )은 사용하지 않는다.
7. 파일 확장자는 포함하지 않는다.

 

+ 추가 자료

https://server-engineer.tistory.com/886

REST API 설계 (네이밍)

 

REST-ful이란?

REST-ful이란 REST API의 설계가이드를 '올바르게' 따라 설계하는 것을 말한다.

모든 CRUD 기능을 POST로 처리 하는 API, URI 규칙을 올바르게 지키지 않은 API 혹은 REST API의 설계 규칙을 올바르게 지키지 못한 시스템은 REST API를 사용하였지만 RESTful 하지 못한 시스템이라고 할 수 있다.

 

REST-ful API 개발 원칙

1. 자원을 식별할 수 있어야한다.

URL (Uniform Resource Locator) 만으로 내가 어떤 자원을 제어하려고 하는지 알 수 있어야 한다. 자원을 제어하기 위해서, 자원의 위치는 물론 자원의 종류까지 알 수 있어야 한다는 의미이다.

 

2. 행위는 명시적이어야 한다.

REST는 아키텍쳐 혹은 방법론과 비슷하다. 따라서 이런 방식을 사용해야 한다고 강제적이지 않다. 기존의 웹 서비스 처럼, GET을 이용해서 UPDATE와 DELETE를 해도 된다.

다만 REST 아키텍쳐에는 부합하지 않으므로 REST를 따른다고 할 수는 없다.

 

3. 자기 서술적이어야 한다.

데이터에 대한 메타정보만 가지고도 어떤 종류의 데이터인지, 데이터를 위해서 어떤 어플리케이션을 실행 해야 하는지를 알 수 있어야 한다.

즉, 데이터 처리를 위한 정보를 얻기 위해서, 데이터 원본을 읽어야 한다면 자기 서술적이지 못하다

 

4. HATEOS(Hypermedia as the Engine of application State)

클라이언트 요청에 대해 응답을 할 때, 추가적인 정보를 제공하는 링크를 포함할 수 있어야 한다.

REST는 독립적으로 컴포넌트들을 손쉽게 연결하기 위한 목적으로도 사용된다. 따라서 서로 다른 컴포넌트들을 유연하게 연결하기 위해선, 느슨한 연결을 만들어줄 것이 필요하다.

이때 사용되는 것이 바로 링크이다. 서버는 클라이언트 응용 애플리케이션에 하이퍼 링크를 제공한다.

클라이언트는 이 하이퍼 링크를 통해서 전체 네트워크와 연결되며 HATEOAS는 서버가 독립적으로 진화할 수 있도록 서버와 서버, 서버와 클라이언트를 분리 할 수 있게 한다.

 

 

---

참고

[Server] Restful API란?

API, REST API, RESTful API 개념정리

stateful, stateless

 

REST에 대하여