Restful API란?

REST라는 단어에 대해선 예전에 포스팅했던 적이 있다.

https://onlyfor-me-blog.tistory.com/228

REST란?

 

이번에는 Restful API라는 말이 무엇인지에 대해 정리하는 포스팅을 쓰려고 한다.

 

Restful이란 단어의 사전적 정의와 연관이 있는지 싶어 찾아보니 "(마음이) 편안한, 평화로운" 이라는 뜻이라, 사전적 정의는 별 도움이 안될 것 같아서 바로 위키백과를 찾아봤다.

 

https://en.wikipedia.org/wiki/Representational_state_transfer

Representational state transfer - Wikipedia

REST 아키텍처 스타일은 6가지 지침 제약 조건을 정의한다. 이런 제약이 시스템 아키텍처에 적용될 때 성능, 확장성, 단순성, 수정 가능성, 가시성, 이식성, 안정성 같은 바람직한 비기능적 속성을 얻는다. 이런 제약 조건 중 일부 또는 전체를 준수하는 시스템을 RESTful이라고 한다.

[웹 서비스에 적용]

REST 아키텍처 제약 조건을 준수하는 웹 서비스 API를 RESTful API라고 한다. HTTP 기반 RESTful API는 다음과 같은 측면으로 정의된다.
- http://api.example.com 같은 기본 URI
- 표준 HTTP 메서드(GET, POST, PUT, DELETE 등)
- 상태 전환 데이터 요소를 정의하는 미디어 유형(Atom, microformats 등). 현재 표현은 클라이언트에게 다음 사용 가능한 모든 애플리케이션 상태로의 전환 요청을 구성하는 방법을 알려준다. 이건 URI처럼 간단할 수도 있고 자바 애플릿처럼 복잡할 수도 있다.

 

REST 제약 조건 6가지를 준수하는 웹 API를 RESTful API라 부른다. 이것은 웹 주소와 HTTP 메서드, 미디어 유형으로 구성된다.

REST의 6가지 제약 조건들은 아래와 같다.

1. 클라이언트-서버 구조 : 클라이언트-서버 디자인 패턴은 UI 문제를 데이터 저장 문제와 분리하는 문제 분리 원칙을 적용한다. 따라서 UI 이식성이 향상된다. 웹의 경우 서버 구현에 대한 지식 없이도 대부분 플랫폼에 대해 과다한 웹 브라우저가 개발됐다. 분리는 또한 서버 구성요소를 단순화해서 확장성을 개선하지만 더 중요한 건 구성 요소가 독립적으로 발전할 수 있게 하는 것(무정부적 확장성)이며, 이는 여러 조직의 도메인을 포함하는 인터넷 규모 환경에서 필요하다.

2. Statelessness(무상태) : 컴퓨팅에서 상태 비저장 프로토콜은 세션 정보가 수신자에 의해 유지되지 않는 통신 프로토콜이다. 관련 세션 데이터는 클라이언트에 의해 전송된 모든 정보 패킷이 세션의 이전 패킷의 컨텍스트 정보 없이 분리되어(단독으로) 이해될 수 있는 방식으로 수신기로 전송된다. 상태 비저장 프로토콜의 이런 속성은 대용량 애플리케이션에서 이상적이며, 세션 정보 보존으로 인한 서버 부하를 제거해 성능을 향상시킨다

3. Cacheability(캐시 가능성) : WWW에서와 같이 클라이언트와 중개자는 응답을 캐시할 수 있다. 응답은 클라이언트가 추가 요청에 대한 응답으로 부실하거나 부적절한 데이터를 제공하는 걸 방지하기 위해 암시적 또는 명시적으로 자신을 캐시 가능 또는 불가능으로 정의해야 한다. 잘 관리된 캐싱은 일부 클라이언트-서버 상호작용을 부분적으로 또는 완전히 제거해 확장성과 성능을 더 향상시킨다.

4. Layered system(계층화 시스템) : 클라이언트는 일반적으로 최종 서버에 직접 연결돼 있는지 아니면 중간에 중개자에게 연결되어 있는지 알 수 없다. 클라이언트와 서버 사이에 프록시 또는 로드 밸런서가 배치되면 프록시 또는 로드 밸런서가 통신에 영향을 주지 않으며, 클라이언트 또는 서버 코드를 수정할 필요가 없다. 중간 서버는 로드 밸런싱을 활성화하고 공유 캐시를 제공함으로써 시스템 확장성을 개선할 수 있다. 또한 웹 서비스 위에 보안을 계층으로 추가해 비즈니스 논리와 보안 논리를 분리할 수 있다. 보안을 별도의 계층으로 추가하면 보안 정책이 적용된다. 마지막으로 중간 서버는 여러 개의 다른 서버를 호출해 클라이언트에 대한 응답을 생성할 수 있다

5. Code on demand(주문형 코드) : 선택사항. 서버는 실행코드(예 : 자바 애플릿 같은 컴파일된 구성요소 또는 자바스크립트 같은 클라이언트 측 스크립트)를 전송해 클라이언트의 기능을 일시적으로 확장하거나 사용자 정의할 수 있다.

6. Uniform interface(균일한 인터페이스) : 이 제약은 RESTful 시스템 설계의 기본이다. 아키텍처를 단순화하고 분리해서 각 부분이 독립적으로 발전할 수 있게 한다. 이 균일한 인터페이스에 대한 4가지 제약 조건은 다음과 같다.
- 요청에서 리소스 식별 : 개별 리소스는 요청에서 식별된다. 예를 들어 RESTful 웹 서비스에서 URI를 사용한다. 리소스 자체는 개념적으로 클라이언트로 반환되는 표현과 별개다. 예를 들어 서버는 DB에서 HTML, XML 또는 JSON으로 데이터를 전송할 수 있으며 이 중 어느 것도 서버의 내부 표현은 아니다.
- 표현을 통한 리소스 조작 : 클라이언트가 연결된 메타데이터를 포함해 리소스의 표현을 보유할 때 리소스의 상태를 수정, 삭제하기에 충분한 정보를 갖고 있다.
- 자체 설명 메시지 : 각 메시지에는 메시지 처리 방법을 설명하기에 충분한 정보가 포함돼 있다. 예를 들어 호출할 파서를 미디어 유형으로 지정할 수 있다.
- HATEOAS(애플리케이션 상태 엔진으로서의 하이퍼 미디어) : REST 응용 프로그램의 초기 URI에 액세스한 경우(웹 사이트의 홈 페이지에 액세스하는 인간 웹 사용자와 유사함) REST 클라이언트는 서버 제공 링크를 동적으로 사용하여 필요한 모든 가용 리소스를 검색할 수 있어야 한다. 액세스가 진행됨에 따라 서버는 현재 사용 가능한 다른 리소스에 대한 하이퍼링크가 포함하는 텍스트로 응답한다. 클라이언트가 애플리케이션의 구조나 역학에 관한 정보로 하드코딩될 필요가 없다.

 

정리하면 REST 아키텍처를 기반으로 API를 만들었으면 그것이 RESTful API다.

그럼 반대로 REST하지 못하다는 말은 어떤 경우에 사용할 수 있을까? 당장 생각나는 건 2가지다.

 

• CRUD 기능을 모두 GET 또는 POST로만 처리하는 API
• 라우트에 리소스, id 외의 정보가 들어가는 경우

 

결론

 

• RESTful API는 REST 설계 원칙을 준수해서 만들어진 API를 말한다
• RESTful API를 만드는 주 목적은 일관적인 규칙을 통한 API 이해도, 호환성을 높이는 것이기 때문에 성능이 중요하다면 굳이 RESTful하게 API를 만들 필요는 없다