API
API는 "Application Programming Interface"의 약어로, 소프트웨어 애플리케이션들이 서로 상호 작용할 수 있도록 허용하는 인터페이스를 의미. 간단히 말해, API는 두 개 이상의 소프트웨어 시스템이 서로 통신하고 상호 작용할 수 있도록 정의된 메소드 및 규약의 모음.
REST(RESTful) API
REST는 "Representational State Transfer"의 약어로, 분산 시스템에서 리소스를 관리하기 위한 아키텍처 스타일. 인터넷 상의 시스템 간의 상호 운용성(interoperability)을 제공하는 방법. REST API는 독립적 진화를 허용하는 것이 설계하는데에 지켜야할 규약이 나오게 된다.
독립적 진화를 허용한다는 것은 RESTful 서비스가 클라이언트와 서버 간의 독립적인 진화를 허용한다는 것을 의미.
서버 측의 변경이나 업데이트가 있더라도 클라이언트에 영향을 주지 않고, 클라이언트 측에서는 서버의 변경을 사전에 알 필요가 없도록 설계된다
-> 즉 REST API는 시스템 간 최소화된 의존성으로 통신하기 위한 방식.
아래의 특징들은 모두 독립적 진화를 허용함으로써 나온 내용들이다.
-
자원(리소스) 지향적
모든 자원(데이터 또는 서비스)은 고유한 식별자(URI)를 갖는다. 클라이언트는 이 URI를 통해 자원을 식별하고 상태를 조작할 수 있음 -
HTTP 메서드 사용
REST API는 HTTP 프로토콜을 사용하여 자원에 대한 작업을 수행.
-
무상태(Stateless) 통신
서버는 클라이언트의 상태를 기억하지 않음. 각 요청은 모든 필요한 정보를 포함하고 있어야 한다. -
캐싱 가능(Cachable)
클라이언트는 응답을 캐싱이 가능하다. 서버는 응답에 캐시 제어 정보를 포함하여 클라이언트가 적절하게 캐싱할 수 있도록 함. -
계층 구조(Layered System)
클라이언트는 서버와 직접 통신할 수 있으며, 필요한 경우 중간 서버(로드 밸런서, 캐시 서버 등)를 통해 통신할 수 있음. -
인터페이스 일관성
URI 디자인과 HTTP 메서드 사용은 일관성을 유지해야 한다. 이는 사용자가 예측 가능하고 이해하기 쉬운 API를 사용하기 위함.
REST API는 다양한 형태의 데이터를 전송할 수 있으며, JSON 또는 XML 형식의 데이터를 주로 사용. 이러한 특징들로 인해 REST API는 널리 사용되며, 웹 서비스 및 모바일 애플리케이션과 같은 다양한 소프트웨어 시스템 간의 통합에 사용.
https://www.youtube.com/watch?v=RP_f5dMoHFc
REST API에 대한 발표영상 참조
일관된 인터페이스(Uniform Interface)
REST API 중 가장 중요한 특징으로 설계할 때 지켜야할 규약 중 하나이다.
-
Identification of resources (리소스 식별)
각 리소스는 고유한 식별자(URI)로 식별되어야 한다. -
Manipulation of resources through representations (표현을 통한 리소스 조작)
클라이언트는 리소스에 대한 조작을 표현을 통해 수행해야 한다. -
Self-descriptive messages (자기 기술적인 메시지)
각 메시지는 해당 메시지가 어떻게 처리되어야 하는지 충분한 정보를 포함한다. 이는 HTTP 메시지의 헤더 및 상태 코드와 관련이 있음. 클라이언트는 서버로부터 받은 응답을 해석하고 처리할 수 있어야 한다. (메시지를 보고 무엇을 해야하는 건지 이해가 되어야 한다.) -
Hypermedia as the engine of application state (HATEOAS)
클라이언트는 서버로부터 받은 리소스와 연관된 하이퍼미디어 링크를 통해 상태 전이를 수행할 수 있어야 한다. 이는 클라이언트와 서버 간의 상호 작용을 동적으로 만들어내며, 서버 측 리소스의 상태 변화에 대해 클라이언트가 알지 못하더라도 동작할 수 있도록 한다
REST API가 맞는가?
< HTTP/1.1 200 OK
< Server: nginx
< Date: Mon, 26 Sep 2016 09:04:44 GMT
< Content-Type: text/xml;charset=utf-8
< Transfer-Encoding: chunked
< Connection: keep-alive
< Keep-Alive: timeout=5
< Vary: Accept-Encoding
< X-Powered-By: Naver
< Cache-Control: no-cache, no-store, must-revalidate
< Pragma: no-cache
<
<rss version="2.0">
<channel>
<title>Naver Open API - shop ::'가방'</title>
<link>http://search.naver.com</link>
<description>Naver Search Result</description>
<lastBuildDate>Tue, 04 Oct 2016 13:23:58 +0900</lastBuildDate>
<total>17161390</total>
<start>1</start>
<display>10</display>
<item>
<title>허니트립 보스턴백</title>
<link>http://openapi.naver.com/l?AAABWLsQ7CIBRFv+Z1JLzSShkYqLajRmPcG6TQRCgiNunfizdnODnJfX9N2iUMCnoKHYWh/4sSlUtmli7nCExBPRY+bo1xCZaEaTOJ6NWXaKdsSHAB2Lg8gZ2QMmybA0cuqiyx4W0ZZR2KrvJyx2CPV3RQ95fbnDT3r+Fh2kbfz5su7x8wIs7ZjgAAAA==</link>
<image>http://shopping.phinf.naver.net/main_1031546/10315467179.jpg</image>
<lprice>6700</lprice>
<hprice>0</hprice>
<mallName>허니트립</mallName>
<productId>10315467179</productId>
<productType>2</productType>
<brand></brand>
<maker>허니트립</maker>
<category1>패션잡화</category1>
<category2>여행용가방/소품</category2>
<category3>보스턴백</category3>
<category4></category4>
</item>
...
</channel>
</rss>-
self-descriptive X
응답 값이 rss 형식이지만 Content-Type을 보면 단순 text/html로 되어있음. rss에 맞는 header값이 있음. self-descriptive 하지 못하므로 REST API라 볼 수 없다.
응답 메시지만 봐도 해석이 가능해야하므로, 응답을 설명해줄 profile 링크가 있어야 한다. -
HATEOAS O
http://search.naver.com 링크 정보가 포함되어 있음.
HAL
HAL(Hypertext Application Language) 은 RESTful API에서 사용되는 하이퍼미디어 타입 중 하나이다. 이것은 클라이언트와 서버 간의 통신을 위한 자원을 표현하기 위한 형식.
RESTful API는 상태를 전이하는데에 있어서 하이퍼미디어의 개념을 활용한다. 클라이언트는 서버에서 받은 하이퍼미디어를 기반으로 다음에 취해야 할 동작을 결정할 수 있다. HAL은 이러한 하이퍼미디어 원칙을 따르는 하나의 형식. 따라서 HAL은 REST API를 설계하고 구현할 때 사용되며, 클라이언트와 서버 간의 통신을 단순화하고 유연성을 높이는데 사용. HAL을 사용하면 클라이언트는 하이퍼미디어를 통해 가능한 동작을 자동으로 인식할 수 있으므로, API의 변경에 유연하게 대응할 수 있음.
