본문으로 바로가기

RESTful API 란?

category CS/Computer 2019. 3. 11. 16:18


RESTful API

RESTful API - Roy. T. Fielding 이 만듬

WEB(1991)

어떻게 인터넷에서 정보를 공유할 것인가?

정보들을 하이퍼텍스트로 연결한다. 
표현 형식 : HTML 
식별자 : URI 
전송방법 : HTTP

Microsoft REST API Guidelines(2016)

  • uri는 https://{serviceRoot}/{collection}/{id} 형식이어야 한다.

  • GET, PUT, DELETE, POST, HEAD, PATCH, OPTIONS를 지원해야 한다.

  • API 버저닝은 Major.minor로 하고, URI에 버전 정보를 포함시킨다… 등

–> Roy. T. Fielding said… 
“이것도 REST API 아님. 그냥 HTTP API 임.” 
“REST APIs must be hypertext-driven” 
“REST API를 위한 최고의 버저닝 전략은 버저닝을 안 하는 것”

REST(Representational State Transfer)

*분산 하이퍼미디어 시스템(예:웹)을 위한 아키텍처 스타일 
(아키텍처 스타일 : 제약조건의 집합)

REST를 구성하는 스타일

  • client-server

  • stateless

  • cache

  • uniform interface

    • 리소스가 uri로 식별

    • http 메시지에 데이터를 담아 목적을 달성

    • ★ 메시지는 스스로를 설명해야 함 (GET /HTTP/1.1 Host:www.example.com(동작, 목적 설명)) 
      요즘은 메시지에 json이라고만 써있지, 자세한 상태는 알지 못함.

    • ★ 애플리케이션의 상태는 Hyperlink 를 이용해 전이되어야 한다. (a tag 클릭시 화면 이동)

    • ★★ 서버의 기능이 변경되어도 클라이언트를 업데이트할 필요가 없다 ★★ REST 목적

  • layered system

  • code-on-demand(optional) (서버에서 코드를 클라이언트로 보내 실행할 수 있어야함 : Javascript)

RESTFul 사례

  • 웹 페이지를 변경했다고 웹 브라우저를 업데이트 할 필요는 없다.

  • 웹 브라우저를 업데이트했다고 웹 페이지를 변경할 필요도 없다.

  • HTTP 명세가 변경되어도 웹은 잘 동작한다.

  • HTML 명세가 변경되어도 웹은 잘 동작한다.

REST가 웹의 독립적 진화에 도움을 주었나

  • HTTP에 지속적으로 영향을 줌

  • Host 헤더 추가

  • 길이 제한을 다루는 방법 명시 (414 URI Too Long 등)

  • URI에서 리소스의 정의가 추상적으로 변경됨 “식별하고자 하는 무언가”

  • HTTP/1.1명세 최신판에서 REST에 대한 언급이 들어감

-> REST는 웹의 독립적 진화에 도움을 줌

왜 API는 REST가 잘 안되나?

 Media Type이 관건. But, 필수는 아님. 
(Media Type이 IANA에 등록되면 처음 보는 사용자도 사용 가능.)


Json은 id 가 무엇이고, title이 무엇을 뜻하는지 모른다. -> Self-descriptive못함. 
다음 상태로 전이할 링크가 없다. ->  HATEOAS 못함.


Self-descriptive : 확장 가능 
HATEOAS : 애플리케이션 상태 전이의 late binding. 링크는 동적으로 변경될 수 있다.


JSON 을 REST 방식으로 바꾸기

> Self-descriptive 만족시키기 

-> 매번 미디어 타입 등록해야 한다.

> HATEOAS 만족시키기


정리

  • 오늘날 대부분의 “REST API”는 사실 REST를 따르지 않고 있다.

  • REST의 제약조건 중에서 특히 Self-descriptive와 HATEOAS를 잘 만족하지 못한다.

  • REST는 긴 시간에 걸쳐(수십년) 진화하는 웹 애플리케이션을 위한 것이다.

  • REST를 따를 것인지는 API를 설계하는 이들이 스스로 판단하여 결정해야 한다.

  • REST를 따르겠다면, Self-descriptive와 HATEOAS를 만족시켜야 한다.

    • Self-descriptive는 custom media type이나 profile link relation등으로 만족시킬 수 있다.

    • HATEOAS는 HTTP 헤더나 본문에 링크를 담아 만족시킬 수 있다.



이 포스팅은

그런 REST API로 괜찮은가 : https://www.youtube.com/watch?v=RP_f5dMoHFc

영상을 글로 정리했습니다.