REST
REST란 REpresentational State Transfer의 약자로, 인터넷의 아키텍처 원리 중 하나입니다.
REST는 웹 서비스를 구현하기 위한 아키텍처 스타일로, 클라이언트와 서버 간의 통신을 위한 규칙을 제공합니다.
이 규칙은 HTTP 프로토콜에 기반하며, 자원(Resource)의 상태(State)를 나타내는 표현(Representation)을 전송하는 것을 중심으로 이루어집니다.
REST는 네트워크 아키텍처를 간단하게 만들어주는 장점이 있습니다. REST API는 클라이언트와 서버 간의 상호작용을 가능하게 하며, 다양한 클라이언트와 서버에서 동작할 수 있도록 플랫폼과 언어에 독립적입니다.
또한 REST API는 CRUD(Create, Read, Update, Delete) 기능을 지원하며, URI(Uniform Resource Identifier)를 통해 자원을 식별하고, HTTP Method(GET,POST,PUT,DELETE)를 통해 자원에 대한 행위를 정의합니다. 이를 통해 REST API를 사용하면 쉽게 데이터를 조회, 추가, 수정, 삭제할 수 있습니다.
URI/URL/URN
URI(Uniform Resource Identifier)는 인터넷에서 식별 가능한 유일한 자원을 나타내는 문자열입니다. URI는 인터넷에서 자원을 식별하기 위한 통일된 방식으로, URL(Uniform Resource Locator)과 URN(Uniform Resource Name) 두 가지 종류가 있습니다.
URL은 인터넷에서 자원의 위치를 나타내는 주소를 의미하며, 일반적으로 웹 페이지를 요청할 때 사용됩니다. 예를 들어, "http://www.example.com/index.html"은 인터넷에서 웹 사이트의 메인 페이지인 "index.html" 파일이 위치한 주소를 나타냅니다.
URN은 인터넷에서 자원의 이름을 나타내는 식별자를 의미합니다. 예를 들어, "urn:isbn:0451450523"은 책의 ISBN 번호를 나타내는 URN입니다.
URI "https://www.example.com/products/1234"에서 URN(Uniform Resource Name)은 식별자(identifier) 부분인 "1234"를 말합니다. URN은 인터넷 상의 자원을 고유하게 식별하기 위한 문자열로, 해당 자원의 위치나 경로를 나타내지 않습니다.
즉, 위의 URI에서 URL은 "https://www.example.com/products/1234"이고, URN은 "1234"입니다.
다른 특성으로, URN은 주로 정보 리소스의 이름을 식별하기 위해 사용되며, 리소스의 위치가 변경되어도 URN은 변하지 않습니다. 예를 들어, "urn:isbn:0451450523"은 책의 ISBN 번호를 식별하기 위한 URN입니다. 이 URN은 책의 위치나 경로를 나타내지 않지만, 책의 ISBN 번호를 고유하게 식별할 수 있습니다.
REST 인터페이스 규칙
- 클라이언트-서버 구조: 클라이언트와 서버는 독립적으로 개발되어야 하며, 서로간에 영향을 주지 않아야 합니다.
- 상태 없음 (Statelessness): 모든 요청은 클라이언트의 상태와 관련된 정보를 서버에서 유지하지 않고, 요청시마다 모든 정보를 제공해야 합니다.
- 캐시 가능 (Cacheability): 클라이언트는 응답을 캐싱할 수 있어야 하며, 서버는 응답을 캐싱 가능하도록 만들어야 합니다.
- 계층화 (Layered System): 서버는 중간 계층(로드 밸런서, 캐시 서버 등)을 사용하여 확장성을 높일 수 있어야 합니다.
- 인터페이스 일관성 (Uniform Interface): 모든 리소스에는 고유한 식별자가 있어야 하며, 리소스를 조작하는 방법은 일관성 있게 설계되어야 한다. 이러한 인터페이스는 자기 서술적(self-descriptive)이며, Hypermedia As The Engine Of Application State(HATEOAS)를 준수해야 합니다.
** 인터페이스 일관성에 대해 자세히 알고자 한다면?
인터페이스 일관성 (Uniform Interface)는 REST 아키텍처의 하나의 원칙으로, 모든 리소스에는 고유한 식별자가 있어야 하며, 리소스를 조작하는 방법은 일관성 있게 설계되어야 한다는 것을 의미합니다.
고유한 식별자 (URI)를 가진 리소스는 클라이언트가 요청하는 리소스를 식별하고, 서버가 클라이언트에게 전달하는 리소스를 식별할 수 있습니다. 이러한 식별자는 클라이언트와 서버 간의 통신을 가능하게 하며, URI를 통해 리소스를 가져오거나 수정하는 등의 작업을 수행할 수 있습니다.
리소스를 조작하는 방법은 일관성 있게 설계되어야 합니다. 즉, 모든 리소스는 일관된 인터페이스를 제공해야 합니다. 이것은 클라이언트가 리소스를 조작하는 방법을 학습하고, 이를 사용하여 서버와 상호 작용하는 데 필요한 지식을 유지하는 것을 의미합니다.
인터페이스 일관성은 또한 자기 서술적(self-descriptive)이어야 합니다. 이것은 클라이언트가 리소스와 상호 작용할 때 필요한 모든 정보가 메시지 내부에 포함되어 있어야 함을 의미합니다. 예를 들어, 응답 메시지에는 리소스 타입, 지원되는 작업, 인증 및 캐싱 규칙 등의 정보가 포함되어 있어야 합니다.
마지막으로, 인터페이스 일관성은 Hypermedia As The Engine Of Application State (HATEOAS)를 준수해야 합니다. 이것은 리소스의 상태를 전이하기 위해 하이퍼미디어 링크를 사용하는 것을 의미합니다. 클라이언트가 리소스와 상호 작용할 때, 링크를 사용하여 리소스 간의 관계와 가능한 작업을 탐색하고, 이를 통해 상태를 전이할 수 있습니다. 이렇게 하면 서버가 변경되거나 리소스가 이동하더라도 클라이언트의 변경 사항이 최소화됩니다
- 자기 서술적 메시지 (Self-descriptive Messages): 각 요청과 응답은 메시지 내부에 자신을 설명하는 정보를 포함해야 합니다.
- 분리된 계층 (Separation of Concerns): 서버의 기능은 가능한 한 작게 유지하고, 서버의 컴포넌트는 각각의 역할을 분리해야 합니다.
리소스의 상태 전이
리소스의 상태를 전이(transition)한다는 것은 리소스의 상태가 변할 때, 클라이언트가 서버와 상호 작용하여 이전 상태에서 새로운 상태로 이동하는 것을 말합니다.
REST에서는 하이퍼미디어 링크를 사용하여 리소스 간의 관계와 가능한 작업을 나타냅니다. 이러한 링크를 통해 클라이언트는 현재 상태에서 가능한 다음 상태로 이동할 수 있는 방법을 찾을 수 있습니다.
예를 들어, 블로그 게시물을 작성하는 REST API를 생각해보면, 클라이언트는 게시물 작성을 위해 POST 요청을 보내야 합니다. 이 요청에는 게시물의 내용이 포함되어 있어야 하며, 서버는 이 내용을 저장한 후, 새로운 게시물의 URI를 생성하여 응답으로 보내줍니다. 이때, 응답에는 생성된 게시물의 URI와 함께 새로운 게시물을 가져오거나 수정하는 데 사용할 수 있는 링크가 포함될 수 있습니다.
이후, 클라이언트는 이 링크를 사용하여 새로 작성한 게시물을 가져오거나 수정할 수 있습니다. 이렇게 링크를 사용하여 클라이언트가 리소스 간의 관계와 가능한 작업을 탐색하고, 이를 통해 상태를 전이하는 것이 REST 아키텍처에서 하이퍼미디어를 이용한 상태 전이(Hypermedia as the Engine of Application State, HATEOAS)입니다.
'단순용어정리 > web' 카테고리의 다른 글
| [간단 정리] 스크린 리더과 시멘틱 웹 (0) | 2023.07.23 |
|---|---|
| [단순용어] httpOnly (0) | 2023.03.14 |
| [단순용어] ReactJS 와 NextJS (0) | 2023.03.07 |
| [단순용어] CORS 와 Access-Control-Allow-Origin (0) | 2023.03.06 |
| [단순용어] 자바스크립트에서 함수형 프로그래밍의 정의/장점/단점 (0) | 2023.03.04 |