URI/URL/URN, Restful 원칙

개요

 

기존 개념의 추가 정의 시간이다.

알고는 있었지만 명확하게 설명하지 못했던 내용들을 다시 복기하고, 정리하고자 한다.

 

Restful을 설명하기 전에, 헷갈렸던 URI/URL부터 짚고 넘어가 보자.

 

 

URI/URL/URN

 

가볍에 알아보는 도식도

1. URI (Uniform Resource Identifier)

• 정의: URI는 인터넷에서 자원을 식별하는 데 사용되는 문자열이다. '자원'은 웹 페이지, 문서, 이미지, 파일, 그리고 백엔드에서 자주 사용하는 API Endpoint 를 포함하는 개념이다.
• 기능: URI는 특정 자원을 식별하고, 해당 자원이 어떻게 접근될 수 있는지에 대한 정보를 제공한다.
• 종류: URI에는 두 가지 주요 형태가 있다.
  • URL (Uniform Resource Locator)
  • URN (Uniform Resource Name)

URI이지만 URL과 URN이 아닌 예시?

URI 중에서 URL이나 URN에 해당하지 않는 예시는 드물고 사용되지 않는다.

대부분의 URI는 URL으로 사용된다. (웹 사이트의 주소 - 특정 자원을 주소로 나타내는 그 방식 말이다.)

 

그러나 이론적으로 가능하긴 하다. 이러한 URI는 자원을 식별하지만, 그 자원의 위치(URL)나 이름(URN)을 구체적으로 지정하지 않는 경우를 뜻한다.

 

예를 들어, 어떤 시스템에서 내부적으로 사용되는 식별자는 URI일 수 있지만,

외부적으로 접근 가능한 위치(URL)나 표준화된 이름(URN)을 갖지 않는 경우로, 이렇게 쓰는 일은 지양해야 한다.

2. URL (Uniform Resource Locator)

 

URL은 실제 주소와, 자원의 위치(API 엔드포인트 등)를 포함한 개념이다.

 

• 정의
  URL은 인터넷 상의 자원이 실제로 어디에 위치하고 있는지를 나타내는, URI의 가장 흔한 형태이다. 
  우리가 일반적으로 사용하는 웹 사이트의 주소라고 할 수 있겠다. 이는 실제 자원의 위치와 쿼리 스트링 등 자세한 정보를 포함한다.
• 특징
  따라서 URL은 자원의 위치를 나타내며, 해당 자원에 접근하기 위해 필요한 모든 정보(프로토콜, 도메인 이름, 경로 등)를 포함한다.

예시

"http://www.example.com/products?category=books&name=john"

 

1. 프로토콜 : "http://"는 웹에서 자원을 어떻게 접근할지 정하는 프로토콜을 나타낸다.

2. 도메인 이름: "www.example.com"은 인터넷 상의 위치(도메인)를 가리킨다.

3. 경로: "/products"는 서버 내에서 특정 자원이나 페이지를 가리키는 경로다.

 

3. URN (Uniform Resource Name)

• 정의
  URN은 (Uniform Resource Name)의 줄임말이다. URI의 표준 포맷 중 하나로, 이름으로 리소스를 특정하는 URI이다.
  
• 특징
  자원의 이름을 제공하지만, 그 자원이 어디에 위치해 있는지, 어떻게 접근해야 하는지에 대한 정보는 포함하지 않는다는 특징을 가진다.
• 예시
  URN은 자원의 위치가 바뀌더라도 해당 자원을 일관되게 식별할 수 있도록 설계되었다.
  예를 들어, ISBN 번호는 책의 URN으로 사용할 수 있을 것이다.
  이러한 경우  http와 같은 프로토콜을 제외하고 리소스의 name을 가리키는데 사용된다.
  

  

  URL과 URN의 차이

그렇다면 URN과 URL의 차이는 뭐죠? (핵심)

• URL은 어떻게 리소스를 얻을 것이고 자원이 어디에 있는지 명시하는 URI이다.
• URN은 이러한 명시 없이 경로와 리소스 자체를 특정하는 것을 목표로 하는 URI이다.

 

Restful

Restful 정의

 

RESTful 설계란 웹 서비스를 구축할 때 사용되는 아키텍처 스타일로, 'Representational State Transfer'의 약자이다.

이는 웹 표준 HTTP를 기반으로 하여 클라이언트와 서버 간의 상호작용을 간소화하고 효율적으로 만들기 위해 설계되었다.

 

클라이언트 - 서버 간의 상호작용을 간소화하는 아키텍쳐 스타일

 

 

RESTful의 핵심 원칙

 

1. 리소스 기반

RESTful 설계의 핵심은 모든 서버의 데이터나 기능이 리소스로 표현되고, 각 리소스는 고유한 URI를 가진다는 점이다.

이는 RESTful 설계의 가장 기본적이고 중요한 특징이다.

 

2. HTTP 메서드 사용

RESTful 서비스는 HTTP 메서드(GET, POST, PUT, DELETE 등)를 사용하여 리소스에 접근한다.

이를 통해 표준화된 방식으로 리소스를 생성, 읽기, 수정, 삭제할 수 있습니다.

 

3. 무상태성(statelessness)

서버가 클라이언트의 상태를 저장하지 않는다.
이 원칙을 통해 시스템의 확장성과 간소화를 진행할 수 있다. 각 요청은 독립적이며 필요한 모든 정보를 포함해야 한다.

 

4. 클라이언트-서버 아키텍처

클라이언트와 서버가 서로 독립적으로 진화할 수 있도록 해야 한다.
당연한 이야기지만, JSP 등으로 SSR을 구현할 경우 RestFul한 설계는 필요 없을 것이다. (서버 - 클라이언트 통신을 할 필요도 없고, 서버 내에 종속된다.)

 

RESTful API 개발 원칙

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

• URL (Uniform Resource Locator) 만으로 내가 어떤 자원을 제어하려고 하는지 알 수 있어야 한다.
  자원을 제어하기 위해서, 자원의 위치는 물론 자원의 종류까지 알 수 있어야 한다는 의미이다.
• Server가 제공하는 정보는 JSON 이나 XML 형태로 HTTP body에 포함한다.
  이를 통해 규격화되고 Stateless하지만 모든 상태를 알 수 있게 된다. (이전에 뭘 받았던지 이전 정보 없이 현재 수신된 정보만으로 요청을 처리할 수 있어야 한다.)

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

• REST는 아키텍쳐 혹은 방법론과 비슷하다. 강제적으로 이를 맞추지 않는다고 해서 고장나거나 사용하지 못하는 것은 아니라는 뜻이다. GET 요청을 이용해서 UPDATE와 DELETE를 해도 된다. 
  물론, Body에 json 등의 객체를 담을 수 없고 Header나 Param 등으로 이상하게 자원을 수신해야겠지만.
• 다만 이러한 사용은 REST 아키텍쳐에는 부합하지 않으므로 REST를 따른다고 할 수는 없다.

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

클라이언트가 서버로부터 받은 응답만을 가지고도,
그 데이터가 어떤 종류의 데이터인지, 그리고 그 데이터를 어떻게 처리해야 하는지를 알 수 있어야 한다.

• 즉, 데이터 처리를 위한 정보를 얻기 위해서, 데이터 원본을 읽어야 한다면 자기 서술적이지 못하다.
  
• 자기 서술적인 메시지는 데이터와 함께 데이터를 해석하고 처리하는 데 필요한 모든 정보(메타데이터)를 포함한다.
  

 

예를 들어, RESTful API에서 클라이언트가 서버에 특정 리소스를 요청했다고 하자.

서버의 응답은 단순히 데이터(JSON 형식의 사용자 정보)뿐만 아니라, 이 데이터를 어떻게 해석해야 하는지에 대한 정보도 포함해야 한다. 아래와 같은 메타데이터가 포함될 수 있겠다.

• HTTP 헤더
  응답에는 Content-Type 헤더가 포함되어 있어야 한다.
  예시로 Content-Type: application/json은 응답 본문이 JSON 형식임을 나타낼 것이다.
  
  
• 링크와 액션
  응답 데이터에는 해당 데이터와 관련된 다른 API 엔드포인트에 대한 링크가 포함될 수 있다.
  예를 들어, 사용자 정보에는 사용자의 프로필 사진을 가져올 수 있는 링크가 포함될 수 있다.

 

 

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

 

클라이언트가 서버와 상호작용할 때 필요한 모든 정보를 응답 내에서 하이퍼미디어를 통해 제공해야 한다는 개념이다.

이 원칙에 따르면, API의 응답은 단순히 데이터만 제공하는 것이 아니라, 클라이언트가 다음에 수행할 수 있는 작업들에 대한 링크도 포함해야 한다.

 

HATEOAS의 중요성

• 유연한 연결
  HATEOAS는 서로 다른 컴포넌트들 사이의 유연한 연결을 가능하게 한다.
  API 사용자는 서버가 제공하는 링크를 통해 어떤 행동을 할 수 있는지, 어떤 상태로 이동할 수 있는지를 알 수 있다.
• 독립적 진화
  HATEOAS는 서버와 클라이언트가 서로 독립적으로 진화하고 유지될 수 있도록 지원한다.
  클라이언트는 고정된 URL 대신 응답에서 제공되는 링크를 사용하여 서버와 상호작용하므로, 서버의 변경이 클라이언트에 미치는 영향을 최소화할 수 있다.

예시

예를 들어, 클라이언트가 어떤 사용자의 정보를 요청하는 경우를 살펴보자.

 

{
  "id": 123,
  "name": "John Doe",
  "links": [
    {"rel": "self", "href": "http://api.example.com/users/123"},
    {"rel": "friends", "href": "http://api.example.com/users/123/friends"},
    {"rel": "profile", "href": "http://api.example.com/users/123/profile"}
  ]
}

 

다음과 같이 links를 통해 연결과 독립성을 시행할 수 있다.

• 하이퍼링크 포함
  응답에는 사용자의 기본 정보 뿐만 아니라, 사용자의 프로필, 친구 목록 등으로 이동할 수 있는 링크들이 포함되어 있다.
• 클라이언트의 독립성
  클라이언트는 이러한 링크를 사용하여 다른 리소스에 접근할 수 있으며, 서버의 구조나 URL 변경에 영향을 받지 않는다.

 

개인적인 생각 : 사실 우리의 토이 프로젝트는 RestFul이 아니다.

 

사실 우리가 토이 프로젝트에서 사용하고 있는 Restful은 정확한 Restful이 아니다.

왜냐하면 HTTP 응답 시 명확하게 어떤 데이터가 특정 기능인지를 알려줘야 하는데, 이것이 약식으로 진행되기 때문이다. 엄밀하고 정확하게 하자면, 이러한 Restful을 맞추기 위해서는 프로토콜 규약에 맞게 문서화를 시행하여 공식 레퍼런스에 등록하거나, 혹은 Body를 통해 이것이 어떤 역할을 하는지 명확하게 설명해주어야 한다.

 

RESTful API를 잘 설계하기 위해서는 API의 행동 방식과 리소스에 대한 명확한 문서화가 필요하다.

이는 클라이언트 개발자가 API를 이해하고 올바르게 사용할 수 있도록 도울 것이다.

 

REST의 단점들

1. REST는 point-to-point 통신모델을 기본으로 한다. 따라서 서버와 클라이언트가 연결을 맺고 상호작용해야하는 어플리케이션의 개발에는 적당하지 않다.
2. REST는 URI, HTTP 이용한 아키텍처링 방법에 대한 내용만을 담고 있다. 보안과 통신규약 정책 같은 것은 전혀다루지 않는다. 따라서 개발자는 통신과 정책에 대한 설계와 구현을 도맡아서 진행해야 한다.
3. HTTP에 상당히 의존적이다. REST는 설계 원리이기 때문에 HTTP와는 상관없이 다른 프로토콜에서도 구현할 수 있기는 하지만 자연스러운 개발이 힘들다. 다만 REST를 사용하는 이유가 대부분의 서비스가 웹으로 통합되는 상황이기에 큰 단점이 아니게 되었다.
4. CRUD 4가지 메소드만 제공한다. 대부분의 일들을 처리할 수 있지만, 4가지 메소드 만으로 처리하기엔 모호한 표현이 있다.

 

레퍼런스

 

https://velog.io/@kimdukbae/URI-URL-URN

URI & URL & URN

 

https://hanamon.kr/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-%EA%B8%B0%EB%B3%B8-url-uri-urn-%EC%B0%A8%EC%9D%B4%EC%A0%90/

[네트워크/기본] URI, URL 및 URN의 차이점 - 하나몬

 

https://www.redhat.com/en/topics/api/what-is-a-rest-api

What is a REST API?

 

https://velog.io/@somday/RESTful-API-%EC%9D%B4%EB%9E%80

RESTful API 이란