원문: https://radixweb.com/blog/rest-vs-restful-api
REST API가 뭘까요?
REST API는 데이터에 접근하고 사용하려는 HTTP 요청을 사용하는 API를 위한 아키텍처 스타일이며, API 교환을 인터넷 상에서 안전하게 이뤄지도록 합니다. REST API는 두 컴퓨팅 시스템이 상호작용하기 위한 방법입니다.
REST API는 인터넷에서 무언가를 검색하는 동안 요청한 서비스에 대한 결과를 얻도록 도와주는 것과 비슷한 방식으로 작동합니다. 200년에 Roy Fielding은 REST API 스펙에 대한 컨셉을 소개했는데, 그 스펙은 나중에 현대 소프트웨어 엔지니어링의 주된 관례가 됐습니다.
API는 기본적으로 규칙들의 집합체로 개발자들이 서버 쪽에서 생성해서 프로그램끼리 소통이 가능하도록 만드는 것입니다. 그리고 REST는 API가 어떻게 보이고, 일하고, 이를 구축하기 위해 개발자들이 어떤 아키텍처 패턴을 따를지 결정합니다.
REST API의 핵심 원칙 중 일부
- 계층화 시스템: REST 요소들은 정해진 계층 외에 간섭해서는 안됩니다. 이 원칙은 확장성을 향상시키고 프록시와 로드 밸런서 추가를 쉬워지게 합니다.
- 통일된 인터페이스: REST 아키텍처 패턴에서 가장 중요한 특성이며 모든 구성 요소의 균일성에 중점을 두고 있습니다.
- 캐싱: REST 서버는 성능 향상을 위해 캐시 불가능한 정보를 폐기하고 필요한 정보를 캐싱할 수 있도록 자신의 응답을 캐시 가능 여부로 식별해야 합니다.
- Stateless: REST 애플리케이션에서 클라이언트는 애플리케이션 상태를 유지해야하지만, 서버는 어떤 클라이언트 상태도 관리해서는 안됩니다. 서비스 요청은 프로세스에 필요한 모든 정보로 구성됩니다.
RESTful API가 뭘까요?
RESTful API는 두 개의 서로 다른 시스템이 긴밀한 보안으로 인터넷을 통해 정보를 교환할 수 있는 인터페이스입니다. RESTful API는 다양한 프로그래밍 언어와 플랫폼에 적용이 가능한 확장 가능하고 간단한 API 구성 방법을 제공합니다.
요즘 RESTful API는 REST 아키텍처 제약조건들을 적용하고 따르고 있으며(API라면 준수해야 하는 일련의 프로토콜), 확장 가능하고, 빠르고, 모든 타입의 데이터를 지원하는 것이 가능해졌습니다. 이런 종류의 API는 HTTP 요청을 사용하는 데이터에 접근합니다. 그리고 동시에 웹 개발 스택에서 가장 흔한 타입의 API이기도 합니다.
RESTful API를 구성하는 주요 요소
- 헤더: HTTP 헤더의 도움을 받아 RESTful API는 요청 메시지와 유효한 응답에 대한 정보를 관리합니다. 예를 들어 connection type, 프록시, 메타데이터 같은 정보들 말입니다.
- 데이터: 데이터는 클라이언트단에서 요청한 자원 정보를 더 많이 담고 있는 body에 해당합니다. 클라이언트가 헤더에서 content type을 정할 때, body는 실질적인 내용을 담고 있습니다.
- 메서드: RESTful API는 서버가 원활하게 동작하도록 DELETE, POST, GET 같은 특정 HTTP 메서드를 활용해서 데이터를 조작합니다.
- Endpoints: URL은 서버 상 데이터 위치를 결정합니다. Endpoints는 기본적으로 우리가 API를 통해 접근하기 위해 시도하는 자원들입니다.
RESTful 웹서비스 혹은 API는 이점들을 제공합니다. 예컨대 더 적은 대역폭을 사용하는 점, 모든 종류의 데이터 형식을 지원한다는 점, 쉬운 러닝 커브를 가지고 있고, 개발자가 처음부터 구축할 필요가 없다는 점 등입니다. 이 API는 SaaS 애플리케이션 개발 영역에서 아주 인기 있으며 공공이든 사적 용도든 상관하지 않고 아주 잘 어울립니다.
미묘하지만, 치명적인 REST / RESTful API의 차이점
이제 REST API가 뭔지, RESTful API가 뭔지 그리고 어떻게 작동하는지 감을 잡았을 겁니다. 그럼 이 둘이 서로 어떻게 다른지 주어진 "매개변수"를 통해 알아봅시다.
1. REST vs RESTful API: 아키텍처
REST 앱의 아키텍처는 계층 시스템과 일관된 UI를 가진 클라이언트 사이드를 가지고 있으며, RESTful 앱은 몇 가지 추가 기능이 포함된 동일한 아키텍처를 가지고 있습니다.
이에 더해 REST 서버는 클라이언트 서버와 함께 유저 상호작용을 다루고, REST 프레임워크는 독립적인 시스템으로 앱 퍼포먼스를 관리합니다.
2. REST vs RESTful API: Consistent UI
이미 언급한 바와 같이, 일관된(혹은 지속적인) UI는 REST 애플리케이션의 핵심 요소 중 하나입니다. REST 아키텍처가 다른 네트워크 기반 패턴들과 다르게 구별 짓는 가장 큰 특성입니다. 그리고 데이터를 자원으로 처리하는 측면에서, RESTful과 REST 시스템 모두 독특하고 유일한 네임스페이스로 이를 처리합니다.
3. REST vs RESTful API: 캐싱 능력
REST API는 캐시 불가능한 데이터를 대체하기 위해 데이터를 캐시 가능/불가능으로 제안하는 반면, RESTful 앱은 클라이언트가 언제 어디서나 캐시 가능한 데이터를 사용할 수 있도록 허용합니다.
쉽게 퍼포먼스와 인프라 시스템으로서 REST 시스템의 기능성을 향상시킬 수 있고, 클라이언트는 데이터를 저장할 수 있게 됩니다. 아무도 저장된 데이터를 사용하지 않을 때는 시스템이 캐싱되지 않은 정보를 제거할 수 있습니다.
반면에, RESTful API를 구축하면 필요할 때마다 캐시 가능한 데이터와 변하지 않는 상태에 어떻게든 접근할 수 있게 됩니다. 또한 대기업들의 웹 개발 트렌드를 따르고 요구 사항에 따라 시스템을 맞춤 설정할 수 있게 해줍니다.
4. REST vs RESTful API: 안정성
REST 앱은 클라이언트 상태를 유지하지 않으며 클라이언트가 각 애플리케이션 단계를 처리합니다. 반면, RESTful 서버는 동일한 실행 과정을 숨겨줍니다.
어떤 서버 요청이든 처리를 위해서 필요한 모든 정보가 포함되어있습니다. RESTful API의 상태에 어떤 변경이 있을 경우, 클라이언트는 저장 용량을 위해 프레임워크에 응답하고 REST 기반 시스템과 대조되는 특정 정보를 얻습니다. 이는 다른 요소로부터 데이터를 보호하기 위해 분산 객체를 사용합니다.
REST 프레임워크에서는 클라이언트와 서버가 상태와 정보에 대해 정보를 교환하는 반면, RESTful 웹 서비스는 어떠한 데이터도 숨기지 않습니다.
5. REST vs RESTful API: Multi-Layered Architecture
REST와 RESTful 사이에서, REST 장치는 할당된 계층을 넘어설 수 없는 반면, RESTful 앱은 여러 계층 간의 데이터 흐름을 용이하게 합니다.
이것이 REST 시스템의 보안 조치와 성능을 향상시키기 위해 프록시나 로드 밸런서를 사용해야 하는 이유입니다. 반대로, RESTful API는 stateless 한계를 통합하여 안전한 경계를 가진 시스템을 만듭니다. 또한, 그 경계 사이의 구분은 매우 명확하고 확실하며, 데이터는 클라이언트의 필요에 따라 한 계층에서 다른 계층으로 흐릅니다. 클라이언트는 데이터를 표시하거나 조작할 수 있는 권한을 가집니다.
