REST API에 대하여 (feat. 로이 필딩 논문)

📌 REST API의 역사

• 웹의 탄생과 초기 웹 (1991년대 초반)
  팀 버너스리(Tim Berners-Lee)가 웹의 기본 구성요소인 HTML, HTTP, URL을 개발하고 웹의 첫 웹 브라우저를 만들었다. 초기 웹은 정적인 컨텐츠를 제공하는 정적인 웹 페이지가 주를 이룸.
  인터넷에서 정보를 공유하는 방법? -> 정보들을 하이퍼 텍스트로 연결한다.

• • 정보의 표현형식 : HTML
  • 정보의 식별자 : URI
  • 정보의 전송방법 : HTTP 프로토콜

 

• 동적인 웹과 서버-클라이언트 상호작용 (1990년대 후반)
  CGI(Common Gateway Interface) 기술을 도입하여 동적인 웹 페이지를 생성할 수 있게 되었다. 
  서버와 클라이언트 사이의 상호작용이 더욱 중요해졌으며, 클라이언트는 서버에 요청을 보내고 서버는 그에 대한 응답을 반환하는 방식으로 웹 서비스가 이루어졌다. 

 

• 웹 서비스와 REST의 등장 (2000년대 초반)
  기존 돌아가던  웹과 호환이 되도록 HTTP를 발전시켜야 함 -> 2000년, 로이 필딩(Roy Fielding) REST 아키텍쳐 논문 발표
  SOAP API VS REST API -> REST API 완승

 

BUT, 진짜 REST API는 어디에?

2008년, CMS를 위한 표준 CMIS가 나왔다 .REST 바인딩을 지원하지만 로이필딩은 REST가 없다고 함.

2016년, 마이크로소프트 REST API 가이드를 만듦. But, 로이필딩은 REST API가 아니다. HTTP API다 라고 함

 

REST APIs must be hypertest-driven

REST? 분산 하이퍼미디어(WEB) 시스템을 위한 아키텍쳐 스타일

 

📌 REST 아키텍쳐

• Client-Server
• Stateless 
• Cache
• Uniform interface
• Layered system
• Code-On-Demand (optional) -> JS

 

Uniform Interface

1. identification of resources
2. manipulation of resources through representations
3. self-descriptive messages
4. HATEOAS (hypermedia as the engine of application state)

 

1. identification of resources (자원에 대한 식별)

자원 : 이름을 지닐 수 있는 모든 정보. 개념적인 대상 ex) 문서, 이미지, 자원들의 집합, 실존하는 대상 등자원은 객체이다. -> 상태는 변화 가능하다. -> 변하지 않는 식별자가 필요하다. URI를 통해 자원을 식별한다. ex) /user/1

 

2. manipulation of resources through representations(표현을 통한 자원에 대한 조작)

특정 상태의 자원에 대한 표현

자원은 다양한 방식으로 표현 가능함 ex) 문서, 파일, HTTP 메세지 엔티티 등

ex) 자원의 현재 상태에 대한 표현
클라 -> 서버 GET /user/1 HTTP /1.1

서버 -> 클라 HTTP/1.0 200 OK

Content-type : text/plain

Content-length : 17

I'm User1

 

REpresentational State Transfer

표현된 (자원의) 상태

 

3. self-descriptive message (자기 서술적 메세지)

메세지는 스스로에 대해 설명해야 한다. 

메시지에는 그 내용을 이해하는 데 필요한 모든 정보가 포함되어 있어야 한다. 이로 인해 클라이언트가 서버와 상호작용할 때 불필요한 추가적인 정보 없이도 요청과 응답을 이해할 수 있게된다.

ex) 서버에서 응답할 때 Host 헤더에 도메인명 기재, Content-Type을 포함함으로써 어디에 어떤 형식의 데이터를 보내는지 명시적으로 나타냄

Get /user/1 HTTP /1.1

host : haesummy.com

Content-Type : text/plain

 

4. HATEOAS

애플리케이션의 상태(한 웹페이지)는 Hyperlink를 이용해 전이되어야한다. 즉 유저가 링크를 선택하면 상태전이(state transfer)가 발생해 다음 상태(페이지)로 넘어간다. .

ex) haesummy.com에서  About  이라는 버튼을 누르면 /about 페이지로 넘어간다.

HTML은 a태그를 통해 다음 상태로 전이가 가능하기 때문에 HATEOAS를 만족한다.

JSON으로는 아래와 같이 전달하면 HATEOAS에 위배되지 않게 만들 수 있다. 

{
	"links" : [
    	{
        	"href":"https://haesummy.com/email",
            "action" :"GET"
        },
        {
        	"href":"https://haesummy.com/about",
            "action" :"GET"
        }]
}

 

📌 REST API여야 할까?

로이필딩은 시스템 전체를 통제할 수 있다고 생각한다면 REST를 따지느라 시간을 낭비하지 말라고 한다. 

결국 Case By Case, 상황바이상황

 

그럼 잘 지켜진 REST API는 뭐가있을까

바로 "WEB"

• 웹 페이지를 변경했다고 웹 브라우저를 업데이트 할 필요 없다.
• 웹 브라우저를 업데이트 했다고 웹 페이지를 변경할 필요 없다.
• HTTP 명세가 변경되어도 웹은 잘 동작한다.
• HTML 명세가 변경되어도 웹은 잘 동작한다.

 

API 설계, 그럼 이제 어떻게 할까?

1. 진짜 REST API를 구현하고 RESTful API라고 부른다.
   • https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
   • https://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm
2. REST API 구현을 포기하고 REST 스타일의 API를 만들어서 HTTP API라고 부른다.
   • https://github.com/microsoft/api-guidelines
   • https://meetup.nhncloud.com/posts/92
3. REST API가 아니지만 REST API라고 부른다. (로이필딩 아저씨가 싫어한다.)
   • https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

 

📌 마치며

대부분의 기업 공고에 보면 RESTful API 경험이 있는 분, 물론 나도 이력서 경험에 그렇게 적어두었다. 요즘은 다들 그냥 REST style의 API를 RESTful API라고 부르는것 같다. (솔직히 REST API로 구현했어요 하는 사람 중 HATEOAS 를 만족하는 API가 얼마나 있을까) 이번 글을 쓰고 로이필딩 아저씨 내 이력서 보면 극대노 하겠네 라는 생각을 했다. ㅋㅋㅋㅋㅋ

애초에 REST API 자체가 "제약"이기 때문에 이런 현상이 생긴게 아닌가 싶다. 만든 아저씨도 이걸 다 지키려 시간낭비 하지 말고 상황에 맞게 하라고 했으니깐. 

로이필드 블로그에 보면 그냥 다른 이름의 어떤 API 라는걸 만들어서 쓰라는 말도 있다. 이해가 가는게 내가 만약 이해선법칙 : 1번, 2번, 3번 을 만족해야함 이라고 정의해놨는데 사람들이 애매하게 80%씩 지키고 이해선법칙이야~! 하는거랑 같은 은 상황아닌가 ㅋㅋㅋㅋㅋ 라는 생각을 했다. 

근데 이미 사람들이 다 그렇게 부르는 용어가 되어버렸는데 앞으로 API 어떻게 구현했다고 하고 다녀야하는거지?

라는 생각을 하며 이번 글을 마무리 한다. 

 

 

📎 참고

https://www.youtube.com/watch?v=RP_f5dMoHFc&ab_channel=naverd2 

https://www.youtube.com/watch?v=Nxi8Ur89Akw&ab_channel=%EC%9A%B0%EC%95%84%ED%95%9C%ED%85%8C%ED%81%AC