Rest API { 개요, API, REST API & Mashup, REST Style, uniform interface style, WEB API & HTTP API }
Ben의 프로그램
2023. 7. 24. 09:38
728x90
수업목표
클라이언트의 종류가 웹 브라우저, 안드로이드 앱, iOS 앱 등 다양해지면서 클라이언트들에게 정보를 제공하는 방식을 하나로 일원화 하고 싶다는 욕구가 개발자들에게 생겨났습니다. 일원화시키는 방식 중에 대표적인 방식이 HTTP프로토콜로 API를 제공하는 것입니다. HTTP프로토콜로 제공하는 API를 REST API라고 합니다. 이번 시간에는 API에 대한 개념과 REST API의 개념에 대해 알아보도록 하겠습니다.
- REST API가 무엇인지 이해합니다. - WEB API(HTTP API)와 REST API를 구분할 수 있습니다.
API 란?
API는 Application Programming Interface 의 약자입니다. API 에 대하여 wiki 에서는 다음과 같이 설명합니다. "API(Application Programming Interface, 응용 프로그램 프로그래밍 인터페이스)는 응용 프로그램에서 사용할 수 있도록, 운영체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스를 뜻합니다." 주로 파일 제어, 창 제어, 화상 처리, 문자 제어 등을 위한 인터페이스를 제공합니다. https://docs.oracle.com/javase/8/docs/api/ 말이 어려운데요. 위의 주소로 들어가보면 java 8 에 대해 Oracle 에서 제공하는 공식 API를 볼 수 있습니다. 자바 언어가 제공하는 클래스와 인터페이스에 대한 설명이 API 문서입니다. API는 프로그래밍 언어가 제공하는 기능을 사용할 수 있도록 인터페이스를 설명하는 문서인데요. 예를 들어 자바에서 절대값을 구하기 위해서는 어떻게 해야 할까요? Java API 문서를 읽어보면 알 수 있습니다. Math 클래스의 abs( )메서드를 사용하면 된다는 것을 알 수 있습니다. '절대 값을 구하려면 Math 클래스의 abs( ) 메서드를 사용하면 되는구나'라는 것을 Java API를 보면 알 수 있지만 실제로 어떻게 구현되어 있는지는 문서를 봐도 알 수 없습니다. 하지만, 해당 라이브러리를 사용할 때 구현코드를 알지 못해도 인터페이스만 알면 사용할 수 있습니다. 이렇게 프로그래밍을 할 때 필요한 인터페이스를 API라고 합니다.
REST API 란? (Mashup)
REST는 REpresentatinoal State Transfer 라는 용어의 약자로 2000년도에 Roy Fielding 의 박사학위 논문에서 최초로 소개되었습니다. REST API란 말 그대로 REST 형식의 API를 말합니다. REST API란 핵심 컨텐츠 및 기능을 외부 사이트에서 활용할 수 있도록 제공되는 인터페이스입니다. 예를 들어, 네이버에서 블로그에 글을 저장하거나, 글 목록을 읽어갈 수 있도록 외부에 기능을 제공하거나 우체국에서 우편번호를 조회할 수 있는 기능을 제공하는 것들을 말합니다. 웹 브라우저 뿐만 아니라 다양한 앱, 기기 등이 클라이언트로 등장하면서 그러한 클라이언트들에게 대응하기 위해 REST API가 널리 사용되기 시작하였습니다. 서비스 업체들이 다양한 REST API를 제공함으로써, 클라이언트는 이러한 REST API들을 조합한 어플리케이션을 만들 수 있게 되었습니다. 이를 Mashup 이라고 합니다.
REST Style
Roy Fielding 이 REST API를 발표한 이후 많은 REST API가 등장하였습니다. 그런데, Roy Fielding 은 다음과 같은 스타일을 지키지 않은 것들은 REST API가 아니라고 말합니다.
- Client server - stateless - cache - uniform interface (*) - layered system - code on demand (optional)
여기서 로이 필딩이 말한 '스타일'은 제약조건의 집합을 의미합니다. 즉, 위에서 말한 조건을 잘 지켜야만 REST 라고 말할 수 있습니다. HTTP 프로토콜을 사용한다면 client server, stateless, cache, layerd system, code on demand 등에 대해서는 모두 쉽게 구현 가능합니다. 문제는 uniform interface 입니다.
uniform interface style
uniform intercface 의 스타일을 살펴보겠습니다.
- 리소스가 URI로 식별되어야 합니다. - 리소스를 생성, 수정, 추가하고자 할 때 HTTP메시지에 표현을 해서 전송해야 합니다. - 메시지는 스스로 설명할 수 있어야 합니다. (Self-descriptive message) - 애플리케이션의 상태는 Hyperlink 를 이용해 전이되어야 합니다. (HATEOAS)
첫 번째와 두 번째 항목은 지키기 어렵지 않은데, 메시지가 스스로 설명할 수 있어야 하는 부분과 HATEOAS 를 지원하는 것은 웹과는 다르게 API로는 쉽지가 않습니다.
세 번째, 메시지가 스스로 설명하는 부분은 왜 어려울까요? 응답 결과에 보통 JSON 메시지(다음 시간에 살펴볼 예정)를 사용하게 되는데, 이 JSON메시지가 어디에 전달되는지 그리고 JSON 메시지를 어떻게 구성해야 메시지 스스로를 설명할 수 있는지 알기가 쉽지 않습니다.
네 번째, HATEOAS 는 왜 어려울까요? 우리가 웹 게시판을 사용할 때, 글 목록을 보면 상세보기와 글쓰기 링크가 있는데요. 상세보기에서는 글 수정이나 글 삭제로 갈 수 있는 링크가 있습니다. 이렇게 웹 페이지를 보면, 웹 페이지 자체에 관련된 링크가 있는 것을 알 수 있는데 이를 HATEOAS라고 말합니다. 이런 HATEOAS를 API 에서 제공하는 것은 쉽지 않습니다.
어려운 REST API, 대신 사용하게 된 Web API & HTTP API
REST의 uniform interface 를 지원하는 것은 쉽지 않기 때문에, 많은 서비스가 REST에서 바라는 것을 모두 지원하지 않고 API를 만들게 됩니다. 이 경우 2가지 경우가 발생하게 됩니다.
- REST의 모든 것을 제공하지 않으면서 REST API라고 말한다 - REST의 모든 것을 제공하지 않고 Web API 혹은 HTTP API라고 말한다.
