[Web] HTTP API와 REST API, RESTful 웹 API 디자인

 

 

HTTP API와 REST API는 거의 같은 의미로 사용되지만 HTTP API는 좀 더 넓은 범위에서 사용된다.

HTTP API는 HTTP 통신 규약을 사용해서 서로 정해둔 스펙으로 데이터를 주고 받으며 통신하는 반면 REST API는 HTTP API에 여러가지 제약 조건이 추가된다.

 

REST는 다음 4가지 제약조건을 만족해야 한다.

- 자원의 식별

- 메시지를 통한 리소스 조작

- 자기서술적 메서지

- 애플리케이션의 상태에 대한 엔진으로서 하이퍼미디어

 

대표적으로 구현하기 어려운 부분이 마지막에 있는 부분으로서 HTML처럼 하이퍼링크가 추가되어서 다음에 어떤 API를 호출해야 하는지를 해당 링크를 통해서 받을 수 있어야 한다. 이런 부분을 완벽하게 지키면서 개발하는 것을 RESTful API라고 하는데 실무에서 이런 방법으로 개발하는 것은 현실적으로 어렵고, 또 추가 개발 비용대비 효과가 있는 것도 아니다. 

 

RESTful한 설계 규칙들 중 2가지의 규칙을 중점적으로 살펴보자.

 

• URI로 자원(리소스)을 표현한다

REST API 는 리소스를 중심으로 디자인되며, 클라이언트에서 액세스할 수 있는 모든 종류의 개체, 데이터 또는 서비스가 리소스에 포함된다. 여기서 리소스마다 해당 리소스를 고유하게 식별하는 URI인 식별자가 있는데 클라이언트가 리소스의 표현을 교환하여 서비스와 상호 작용하게 된다. 많은 Web API가 교환 형식으로 JSON을 사용한다.

https://adventure-works.com/orders/1 (URI)
{"orderId":1,"orderValue":99.90,"productId":1,"quantity":1} (JSON)

 

1. 자원에 대한 행위는 HTTP Method(GET, POST, PUT, PATCH, DELETE)로 표현된다.

     1. GET은 지정된 URI에서 리소스의 표현을 검색한다. 응답 메시지의 본문은 요청된 리소스의 세부 정보를 포함한다.

     2. POST는 지정된 URI에 새 리소스를 만든다. 요청 메시지의 본문은 새 리소스의 세부 정보를 제공한다. 참고로 POST를             사용하여 실제로 리소스를 만들지 않는 작업을 트리거할 수도 있다.

     3. PUT은 지정된 URI에 리소스를 만들거나 대체한다. 요청 메시지의 본문은 만들 또는 업데이트할 리소스를 지정한다.

     4. PATCH는 리소스의 부분 업데이트를 수행한다. 요청 본문은 리소스에 적용할 변경 내용을 지정한다.

      5. DELETE는 지정된 URI의 리소스를 제거한다.

 

 

 

참고 사이트:

https://learn.microsoft.com/ko-kr/azure/architecture/best-practices/api-design 

웹 API 디자인 모범 사례 - Azure Architecture Center

https://www.inflearn.com/questions/126743/http-api-vs-rest-api

HTTP API vs REST API - 인프런 | 질문 & 답변