REST(Representational State Transfer)란 무엇인가?

1. 소개

  REST(Representational State Transfer)는 웹 서비스 및 API를 구축하기 위한 아키텍처 스타일입니다. 2000년 Roy Fielding이 박사 학위 논문에서 처음 소개했으며 이후 API 구축에 가장 널리 사용되는 접근 방식 중 하나가 되었습니다.

 

  REST의 목적은 GET, POST, PUT 및 DELETE와 같은 표준 HTTP 메서드를 사용하여 웹을 통해 데이터와 기능에 액세스하고 조작할 수 있는 간단하고 유연한 방법을 제공하는 것입니다.

 

  RESTful API는 HTTP 요청 및 응답을 사용하여 데이터를 교환하며 웹 브라우저, 모바일 앱 및 서버 측 애플리케이션을 비롯한 다양한 클라이언트에서 사용할 수 있습니다.  단순하고 확장 가능하도록 설계되었으며 작업보다는 리소스에 중점을 둡니다.

 

  REST는 URL을 사용하여 리소스를 식별하고 HTTP 메서드를 사용하여 리소스를 조작하므로 이해하고 사용하기 쉬우며 다양한 기술 및플랫폼. 결론적으로 REST는 API 구축을 위한 강력하고 유연한 아키텍처 스타일이며 단순성과 확장성으로 인해 모든 규모의 조직과 모든 산업 분야에서 널리 사용됩니다.

 

2. RESTful  제약

RESTful 제약 REST는 RESTful API가 작동하는 방식을 정의하는 제약 조건 집합을 기반으로 합니다. 이러한 제약 조건은 RESTful API가 확장 가능하고 유연하며 사용하기 쉬운지 확인하는 데 도움이 됩니다. 다음은 REST의 주요 제약 조건입니다.

• Client-Server Architecture: REST는 애플리케이션을 클라이언트와 서버의 두 부분으로 나눕니다. 클라이언트는 서버에 요청을 하고 서버는 응답을 반환합니다. 이러한 관심사 분리를 통해 애플리케이션을 더 쉽게 구축, 유지 관리 및 발전시킬 수 있습니다. 
• Statelessness: RESTful API는 상태 비저장입니다. 즉, 서버가 요청 간에 클라이언트 상태를 저장하지 않습니다. 이를 통해 API를 더 쉽게 확장하고 데이터 불일치의 위험을 줄일 수 있습니다.
• Cacheability: RESTful API는 캐시 가능해야 합니다. 즉, 클라이언트는 서버에 새로운 요청을 하지 않고도 응답을 캐시하고 재사용할 수 있습니다. 이를 통해 성능을 향상하고 서버의 로드를 줄일 수 있습니다. 
• Layered System: RESTful API는 계층화된 시스템에서 사용할 수 있으며,응용 프로그램의 여러 구성 요소가 분리되어 API를 통해 서로 상호 작용합니다. 이렇게 하면 응용 프로그램의 여러 부분을 보다 쉽게 ​​관리할 수 있으며 한 부분을 변경해도 다른 부분에 영향을 주지 않습니다. 
• Code on Demand (optional): REST를 사용하면 클라이언트가 JavaScript와 같은 코드를 서버에서 다운로드하여 클라이언트의 기능을 확장할 수 있습니다. 이는 선택적 제약 조건이며 실제로는 자주 사용되지 않습니다. 

 

 결론적으로 RESTful 제약 조건은 RESTful API가 확장 가능하고 유연하며 사용하기 쉬운지 확인하는 데 도움이 되며 API 구축을 위한 기술로서 REST가 성공하는 데 핵심적인 역할을 합니다.

 

 

 

3. RESTful Methods

RESTful API는 일련의 표준 HTTP 메서드를 사용하여 리소스와 상호 작용합니다. 다음은 RESTful API에서 사용되는 기본 HTTP 메서드입니다.

• GET: 리소스 또는 리소스 모음을 검색합니다. GET 방식은 서버에서 정보를 가져오는 데 사용되며 RESTful API에서 가장 일반적으로 사용되는 방식입니다.
• POST: 새 리소스를 만듭니다. POST 메서드는 새 리소스를 만들기 위해 서버에 데이터를 제출하는 데 사용됩니다. 이는 종종 새 사용자 또는 새 블로그 게시물과 같은 데이터베이스에서 새 항목을 만드는 데 사용됩니다.
• PUT: 기존 리소스를 업데이트합니다. PUT 메서드는 서버의 기존 리소스를 업데이트하는 데 사용됩니다. 이것은 종종 사용자의 프로필 정보를 업데이트하는 것과 같이 데이터베이스의 기존 항목을 업데이트하는 데 사용됩니다.
• DELETE: 리소스를 삭제합니다. DELETE 메서드는 서버에서 리소스를 삭제하는 데 사용됩니다. 이것은 종종 사용자 계정 삭제와 같이 데이터베이스에서 항목을 삭제하는 데 사용됩니다.
• PATCH: 리소스를 부분적으로 업데이트합니다. PATCH 방식은 전체 리소스를 업데이트하는 것이 아니라 서버의 일부 리소스만 업데이트하는 데 사용됩니다. 이는 사용자의 이메일 주소 업데이트와 같이 리소스의 작은 부분만 업데이트해야 할 때 유용합니다.

이러한 HTTP 메서드는 RESTful API에서 리소스와 상호 작용하는 데 사용되며 서버에서 리소스 상태를 관리하는 간단하고 유연한 방법을 제공합니다. RESTful API는 표준 HTTP 메서드를 사용하여 리소스와 더 쉽게 상호 작용하고 API의 확장성과 유연성을 보장합니다.

 

 

4. RESTful Endpoints

   RESTful 엔드포인트는 RESTful API의 리소스에 액세스하는 데 사용되는 특정 URL입니다. 엔드포인트는 클라이언트가 리소스에 액세스하기 위한 진입점이며 API의 구조와 구성을 정의합니다. Endpoints은 API의 루트를 정의하는 기본 URL과 액세스되는 특정 리소스를 정의하는 특정 리소스 식별자로 구성됩니다. 예를 들어 "황금키워드"와 같은 리소스에 대한 API 끝점은 https://pysyntax.com/황금키워드 정의될 수 있습니다.

 

  RESTful API는 GET, POST, PUT, DELETE 및 PATCH와 같은 표준 HTTP 메서드를 사용하여 리소스와 상호 작용합니다. Endpoints은 특정 HTTP 메서드를 처리하도록 설계되었으며 리소스에 액세스하고 조작하는 방법을 결정합니다. 

 

 Endpoints에는 클라이언트가 리소스를 필터링하고 정렬할 수 있도록 하는 매개 변수도 있을 수 있습니다.  RESTful API에서 엔드포인트는 다음을 정의합니다.리소스의 구조 및 구성을 제공하며 클라이언트가 일관되고 예측 가능한 방식으로 리소스에 액세스하고 조작할 수 있는 방법을 제공합니다.

 

  API는 RESTful Endpoints를 사용하여 클라이언트가 리소스에 액세스할 수 있는 간단하고 유연한 방법을 제공할 수 있으며 API의 확장성과 유연성을 보장할 수 있습니다.

 

 

 

5. RESTful Responses

  RESTful API에서 응답은 클라이언트가 Endpoints에 요청한 후 API에서 반환하는 데이터를 나타냅니다. 응답은 리소스와 상호 작용하는 데 필요한 정보를 클라이언트에 제공하므로 RESTful API의 중요한 부분입니다. 응답은 JSON, XML 및 일반 텍스트를 비롯한 다양한 형식으로 보낼 수 있습니다.

 

  응답 형식은 HTTP 응답의 "Content-Type" 헤더에 의해 결정됩니다. RESTful API는 요청 상태를 나타내는 명확하고 의미 있는 응답 코드를 제공해야 합니다. 일반적인 응답 코드에는 200 OK, 201 Created, 204 No Content, 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found 및 500 Internal Server Error가 있습니다.

 

응답 코드 외에도 RESTful API의 응답에는 요청된 리소스에 대한 정보를 클라이언트에 제공하는 데이터도 포함됩니다. 응답은 구문 분석 및 이해하기 쉬운 방식으로 형식화되어야 하며 리소스에 대한 모든 관련 정보를 포함해야 합니다.

 

RESTful API는 명확하고 의미 있는 응답을 제공함으로써 클라이언트가 일관되고 예측 가능한 방식으로 리소스와 상호 작용하는 데 필요한 정보를 갖도록 보장할 수 있습니다. 이를 통해 API의 확장성과 유연성을 보장하고 클라이언트가 API와 더 쉽게 통합할 수 있습니다.

 

6. RESTful Best Practices

RESTful API가 잘 설계되고 유지 관리 가능하며 확장 가능하도록 하기 위해 개발자가 따라야 하는 여러 모범 사례가 있습니다.

• HTTP 메서드를 올바르게 사용: RESTful API는 각 요청 유형에 대해 적절한 HTTP 메서드를 사용해야 합니다. 예를 들어 GET 요청은 데이터를 검색하는 데 사용해야 하고 POST 요청은 리소스를 만드는 데 사용해야 하며 PUT 요청은 리소스를 업데이트하는 데 사용해야 하며 DELETE 요청은 리소스를 삭제하는 데 사용해야 합니다.
• Design for statelessness: RESTful API는 각 요청이 독립적이고 서버에 저장된 상태 정보에 의존하지 않도록 설계되어야 합니다. 이를 통해 API를 확장 및 유지 관리할 수 있으며 캐싱 및 기타 성능 최적화를 보다 쉽게 ​​구현할 수 있습니다.
• HTTP 응답 코드 사용: RESTful API는 각 요청의 상태를 나타내기 위해 명확하고 의미 있는 HTTP 응답 코드를 반환해야 합니다. 이를 통해 클라이언트는 요청 결과를 쉽게 이해하고 적절한 조치를 취할 수 있습니다.
• 적절한 URL 구조 사용: RESTful API는 액세스 중인 리소스와 수행 중인 작업을 명확하게 나타내는 명확하고 의미 있는 URL 구조를 사용해야 합니다.
• 포괄적인 문서 제공: RESTful API에는 사용 가능한 엔드포인트, 요청 매개변수, 응답 형식 등에 대한 정보를 제공하는 포괄적인 문서가 포함되어야 합니다. 이를 통해 고객은 API와 쉽게 통합하고 이를 효과적으로 사용하는 방법을 이해할 수 있습니다.
• 버전 관리 구현: 시간이 지남에 따라 API가 발전하더라도 클라이언트가 리소스에 계속 액세스할 수 있도록 하려면 RESTful API에 버전을 지정해야 합니다.
• *HATEOAS 사용: RESTful API는 리소스와 상호 작용하는 데 필요한 정보를 클라이언트에 제공하기 위해 HATEOAS(응용 프로그램 상태 엔진)로 Hypermedia를 사용해야 합니다. 이를 통해 API는 유연하고 확장 가능하며 클라이언트는 리소스와 상호 작용하는 방법을 더 쉽게 이해할 수 있습니다.

*HATEOAS(Hypermedia As The Engine Of Application State)란?
 REST(Representational State Transfer) 아키텍처 스타일의 제약 조건입니다. 응답 페이로드에서 링크를 검색하고 따라가서 웹 애플리케이션을 탐색하는 방법을 제공합니다. HATEOAS에서 클라이언트는 미리 정의된 엔드포인트에 의존하는 대신 응답의 링크를 사용하여 다음에 수행할 수 있는 작업을 결정합니다. 이를 통해 보다 동적이고 유연한 클라이언트-서버 상호 작용이 가능하며, 여기서 서버는 클라이언트에서 변경할 필요 없이 사용 가능한 작업을 변경할 수 있습니다. HATEOAS의 목표는 RESTful API를 자체 설명적이고 클라이언트가 쉽게 탐색할 수 있도록 만드는 것입니다.

이러한 원칙들을 따르면 개발자는 RESTful API가 잘 설계되고 유지 관리 및 확장 가능하며 클라이언트가 쉽게 통합하고 효과적으로 사용할 수 있는지 확인할 수 있습니다.

 

7. 결론

  REST(Representational State Transfer)는 웹 서비스 설계에 널리 사용되는 아키텍처 스타일입니다. RESTful API는 클라이언트-서버 아키텍처, Statelessness 및 캐시 가능성과 같은 제약 조건 집합을 포함하는 REST 원칙을 기반으로 하며  또한 GET, POST, PUT 및 DELETE와 같은 일반적인 HTTP 메서드를 사용하여 리소스와 상호 작용합니다.

Endpoints는 클라이언트가 데이터에 액세스하기 위한 진입점이며 응답은 클라이언트에 데이터 및 관련 메타데이터를 제공합니다.HATEOAS는 클라이언트가 API를 탐색하는 데 도움이 되도록 API가 응답 페이로드에 링크를 제공하는 REST의 제약 조건입니다. 즉, RESTful 원칙에 따라 유연하고 확장 가능하며 검색 가능한 웹 서비스를 만들 수 있습니다.