HTTP API vs REST API

HTTP API와 REST API를 혼용해서 사용해왔는데 그 차이점이 무엇인가?에 대해서 의문을 가졌고 이에 대해 찾아 보았다.

사실 HTTP API와 REST API는 거의 같은 의미로 사용된다.하지만 더 디테일하게 찾아본다면 다른 부분도 있는데,HTTP API는 HTTP를 사용해서 서로 정해둔 스펙으로 데이터를 주고 받으며 통신을 한다는 것이다. 그래서 비교적 REST API에 비해 넓은 의미로 사용된다.

반면에 REST API는 HTTP API에 여러가지 제약 조건이 추가된다.REST는 다음 4가지 제약조건을 만족해야 한다.(https://ko.wikipedia.org/wiki/REST)

자원의 식별

-요청 내에 기술된 개별 자원을 식별할 수 있어야 한다. 웹 기반의 REST 시스템에서의 URI의 사용을 예로 들 수 있다. 자원 그 자체는 클라이언트가 받는 문서와는 개념적으로 분리되어 있다. 예를 들어, 서버는 데이터베이스 내부의 자료를 직접 전송하는 대신, 데이터베이스 레코드를 HTML, XML이나 JSON 등의 형식으로 전송한다.

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

-클라이언트가 어떤 자원을 지칭하는 메시지와 특정 메타데이터만 가지고 있다면 이것으로 서버 상의 해당 자원을 변경·삭제할 수 있는 충분한 정보를 가지고 있는 것이다.

자기서술적 메시지

-각 메시지는 자신을 어떻게 처리해야 하는지에 대한 충분한 정보를 포함해야 한다. 예를 들어 MIME type과 같은 인터넷 미디어 타입을 전달한다면, 그 메시지에는 어떤 파서를 이용해야 하는지에 대한 정보도 포함해야 한다. 미디어 타입만 가지고도, 클라이언트는 어떻게 그 내용을 처리해야할 지 알 수 있어야 한다. 메시지를 이해하기 위해 그 내용까지 살펴봐야 한다면, 그 메시지는 자기서술적이 아니다. 예를 들어, 단순히 "application/xml"이라는 미디어 타입은, 실제 내용을 다운로드 받지 않으면 그 메시지만 가지고는 무엇을 해야할지에 대해 충분히 알려주지 못한다.

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

-만약에 클라이언트가 관련된 리소스에 접근하기를 원한다면, 리턴되는 지시자에서 구별될 수 있어야 한다. 충분한 콘텍스트 속에서의 URI를 제공해주는 하이퍼텍스트 링크의 예를 들 수 있겠다.( HTML처럼 하이퍼링크가 추가되어서 다음에 어떤 API를 호출해야 하는지를 해당 링크를 통해서 받을 수 있어야 한다.)

이런 부분을 완벽하게 지키면서 개발하는 것을 RESTful API라 한다. 하지만, 실무에서 이런 방법으로 개발하는 것은 현실적으로 어렵고, 또 추가 개발 비용대비 효과가 있는 것도 아니라고 한다. 하지만 이미 많은 사람들이 해당 조건을 지키지 않아도 REST API라고 하기 때문에, HTTP API나 REST API를 거의 같은 의미로 사용하고 있다.(but, 엄밀히 말하면 REST API는 위와 같은 조건을 다 지켜야 REST API라고 할 수 있다.