REST 소개
2000년에 Roy Fielding은 웹 서비스를 디자인하는 아키텍처 접근 방식으로 REST(Representational State Transfer)를 제안했습니다. REST는 하이퍼미디어 기반 분산 시스템을 구축하기 위한 아키텍처 스타일입니다. REST는 어떤 기본 프로토콜과도 독립적이며 HTTP에 연결될 필요가 없습니다. 그러나 대부분의 일반적인 REST 구현에서 애플리케이션 프로토콜로 HTTP를 사용하고, 이 지침에서는 HTTP를 위한 REST API 디자인에 중점을 둡니다.
REST가 HTTP보다 우수한 주요 장점은 개방형 표준을 사용하므로 API 또는 클라이언트 애플리케이션의 구현이 특정 구현에 바인딩되지 않는다는 것입니다. 예를 들어 REST 웹 서비스는 ASP.NET으로 작성할 수 있으며, 클라이언트 애플리케이션은 HTTP 요청을 생성하고 HTTP 응답을 구문 분석할 수 있는 모든 언어 또는 도구 집합을 사용할 수 있습니다.
요약 : 아키텍쳐 스타일입니다. 여기서 말하는 아키텍쳐 스타일은 '제약 조건의 집합' 또는 '프로토콜' 정도로 봐도 무방합니다. 따라서 Restful 이란, 어떤 '무언가'를 주고 받을 때의 약속을 정의하고, 그 약속을 완벽히 이행했을 때(ful의 의미) 붙여지는 수식어
[출처] RESTful API, REST (Representational status transfer)란?
다음은 HTTP를 사용하는 RESTful API의 몇 가지 기본 디자인 원칙입니다.
-
REST API는 리소스를 중심으로 디자인되며, 클라이언트에서 액세스할 수 있는 모든 종류의 개체, 데이터 또는 서비스가 리소스에 포함됩니다.
-
리소스마다 해당 리소스를 고유하게 식별하는 URI인 식별자가 있습니다. 예를 들어 특정 고객 주문의 URI는 다음과 같습니다.
HTTP
https://adventure-works.com/orders/1 -
클라이언트가 리소스의 표현을 교환하여 서비스와 상호 작용합니다. 많은 Web API가 교환 형식으로 JSON을 사용합니다. 예를 들어 위에 나열된 URI에 대한 GET 요청은 이 응답 본문을 반환할 수 있습니다.
JSON
{"orderId":1,"orderValue":99.90,"productId":1,"quantity":1} -
REST API는 균일한 인터페이스를 사용하므로 클라이언트와 서비스 구현을 분리하는 데 도움이 됩니다. HTTP를 기반으로 하는 REST API의 경우 리소스에 표준 HTTP 동사 수행 작업을 사용하는 것이 균일한 인터페이스에 포함됩니다. 가장 일반적인 작업은 GET, POST, PUT, PATCH 및 DELETE입니다.
-
REST API는 상태 비저장 요청 모델을 사용합니다. HTTP 요청은 독립적이어야 하고 임의 순서로 발생할 수 있으므로, 요청 사이에 일시적인 상태 정보를 유지할 수 없습니다. 정보는 리소스 자체에만 저장되며 각 요청은 자동 작업이어야 합니다. 이러한 제약 조건이 있기 때문에 웹 서비스의 확장성이 우수합니다. 클라이언트와 특정 서버 사이에 선호도를 유지할 필요가 없기 때문입니다. 모든 서버는 모든 클라이언트의 모든 요청을 처리할 수 있습니다. 그렇긴 하지만, 다른 요소가 확장성을 제한할 수 있습니다. 예를 들어 많은 웹 서비스가 백 엔드 데이터 저장소에 쓰기하므로 확장하기 어려울 수 있습니다. 데이터 저장소를 확장하는 전략에 대한 자세한 내용은 가로, 세로 및 기능 데이터 분할을참조하십시오.
-
REST API는 표현에 포함된 하이퍼미디어 링크에 따라 구동됩니다. 예를 들어 다음은 주문의 JSON 표현을 보여줍니다. 주문과 관련된 고객을 가져오거나 업데이트하는 링크를 포함하고 있습니다.
JSON
{
"orderID":3,
"productID":2,
"quantity":4,
"orderValue":16.60,
"links":
[ {"rel":"product","href":"https://adventure-works.com/customers/3", "action":"GET" },
{"rel":"product","href":"https://adventure-works.com/customers/3", "action":"PUT" } ]
}https://adventure-works.com/orders/1
2008년에 Leonard Richardson은 Web API에 대한 다음과 같은 성숙도 모델을 제안했습니다.
- 수준 0: 한 URI를 정의합니다. 모든 작업은 이 URI에 대한 POST 요청입니다.
- 수준 1: 개별 리소스에 대한 별도의 URI를 만듭니다.
- 수준 2: HTTP 메서드를 사용하여 리소스에 대한 작업을 정의합니다.
- 수준 3: 하이퍼미디어(HATEOAS, 아래에 설명)를 사용합니다.
수준 3은 Fielding의 정의에 따르면 진정한 RESTful API에 해당합니다. 실제로 게시된 여러 Web API가 수준 2의 어딘가에 해당합니다.
출처 : https://docs.microsoft.com/ko-kr/azure/architecture/best-practices/api-design
API 디자인 지침 - Best practices for cloud applications
잘 디자인된 Web API를 만드는 방법에 관한 지침입니다.
docs.microsoft.com
REST API
- 요약 : HTTP를 사용하여 인터페이스를 만드는것
- 특징 : 플랫폼의 독립성 가지게 한다(API - Client App간의 독립적으로 서비스 업그레이드 병행이 가능해진다)
- 장점 : UI layer와 DB사이 Busniess Logic 코드분리(Busniess Logic에만 집중 할 수 있는 환경을 구성 해서 Front-end에서 동작이 다양해짐) , 코드의 재사용성 증가
REST API가 되기위한 권장사항
- URL로 요청을 올리면 JSON형태로 데이터 변환
- 리소스를 중심으로 제작(명명시에 명사형으로 URL 구성)
- depth를 3개이상 가지지 않는것을 권장한다( ex - host/컬렉션/항목/컬렉션 )
- 동작은 HTTP 메소드를 활용해 제공한다
- API 결과는 상태코드로 변환 데이터는 JSON형태