RESTful API란?

1. 최근의 추세

전통적인 웹 애플리케이션은 주로 서버사이드에서 화면에 필요한 모든 데이터를 만들어서 브라우

저에 전송해주고，브라우저는 단순 뷰어(viewer) 역할에 그치는 형태였다. 시간이 흘러 모바일 환

경이 대두되면서 이러한 서버의 역할은 많이 달라지고 있다. 서버는 브라우저나 모바일에서 필요

한 순수한 데이터만을 전달하는 API 서버의 형태로 변화하고 있다. 예컨대, 검색 API 서버는 검색

의 결과를 XML이나 JSON의 형태로 전달하고, 브라우저나 모바일에서는 이를 가공해서 사용자에

게 보여주는방식. 모바일 시대가 되면서 WEB 분야의 가장 큰 변화는 서버 역할의 변화라고 할 수 

있습니다. 과거에는 서버의 데이터를 소비하는 주체가 '브라우저’라는 특정한 애플리케이션으로

제한적이었다면，모바일의 시대가 되면서 앱이나 웹은 서버에서 제공하는 데이터를 소비

하게 된다. 과거의 서버는 브라우저라는 하나의 대상만을 상대로 데이터를 제공했기 때

문에 아예 브라우저가 소화 가능한 모든 데이터를 HTML이라는 형태로 전달하고，브라

우저는 이를 화면에 보여주는 역할을 해왔다. 스마트폰에서는 앱(App)이라 불리는 고유한 애

플리케이션을 이용해서 데이터를 소비하게 되고，보이는 화면 역시 자신만의 방식으로 서비스하

게 된다. 앱에서 서버에 기대하는 것은 완성된 HTML이 아니라 그저 자신에게 필요한 순수한 데

이터만을 요구하게 되었습니다. 이처럼 서버의 역할은 점점 더 순수하게 데이터에 대한 처리를 목

적으로 하는형태로 진화하고 있습니다. 또한，브라우저와 앱은 서버에서 전달하는 데이터를 이용

해서앱 혹은 브라우저 내부에서 별도의 방식을 통해서 이를 소비하는 형태로 전환하고 있습

니다.

2. URL과 URI 의 차이점

이러한 변화 속에서 웹의 URI(Uniform Resource Identifier) 의미도 조금 다르게 변화하기 시작했습

니다. 예를 들어 과거에 제작된 웹페이지들의 경우 페이지를 이동하더라도 브라우저의 주소는 변

화하지 않는 방식을 선호했습니다(가장 대표적인 사이트가 네이버의 카페와 같은 경우입니다.). 반

면에 최근의 웹페이지들은 대부분 페이지를 이동하면 브라우저 내의 주소 역시 같이 이동하는 방

식을 사용합니다

흔히 URL(Uniform Resource Locator)과 URI(Uniform Resource Identifier)를 같은 의

미로 사용하는 경우가 많습니다. 엄밀하게는 URL은 URI의 하위 개념이기 때문에 혼용

해도 무방합니다. URI는 자원의 식별자라는 의미로 사용됩니다.

URL은 이 곳에 가면 당신이 원하는 것을 찾을 수 있습니다와 같은 상징적인 의미가

좀 더 강하다면 URI는 당신이 원하는 곳의 주소는 여기입니다와 같이 좀 더 현실적이

고 구체적인 의미가 있습니다. URI의 I는 마치 데이터베이스의 PK와 같은 의미로 사용

된다고 생각할 수 있습니다

3. REST

REST는 Representational State Transfer(대표적인 상태 전달)의 약어로 하나의 URI는 하나의 고유

한 리소스(Resource)를 대표하도록 설계된다는 개념에 전송방식을 결합해서 원하는 작업을 지정합

니다. 예를 들어 /boards/123’은 게시물 중에서 123번이라는 고유한 의미를 가지 도록 설계하고, 

이에 대한 처리는 

GET, POST 방식과 같이 추가적인 정보를 통해서 결정합니다. 따라서 REST 방식은 다음과 같이 구성

된다고 생각할 수 있습니다

URI + GET/POST/PUT/DELETE/....

REST 방식의 데이터 교환에서 가장 특이한 점은 기존의 GET/POST 외에 다양한 방식 으로 데이터를 전달한다는 점입니다. HTTP의 전송방식은 아래와 같은 형태로 사용

REST 방식은 URI와 같이 결합하므로 회원(member)이라는 자원을 대상으로 전송방식 을 결합하면 다음과 같은 형태가 됩니다

스프링은 @RequestMapping이나 @ResponseBody와 같이 REST 방식의 데이터 처리를 위한 여러 종류의 어노테이션과 기능이 있습니다

2. @RestController

REST 방식에서 가장 먼저 기억해야 하는 점은 서버에서 전송하는 것이 순수한 데이터라는 점입니다. 기존의 Controller에서 Model에 데이터를 담아서 JSP 등과 같은 뷰 (View)로 전달하는 방식이 아니므로 기존의 Controller와는 조금 다르게 동작

©Controller 외에 @RestController라는 어노테이션을 추가해서 해당 Controller의 모든 메서드의 리턴 타입을 기존과 다르게 처리한다는 것을 명시

@RestController는 메서드의 리턴 타입으로 사용자가 정의한 클래스 타입을 사용할 수 있고，이를 JSON이나 XML로 자동으로 처리할 수 있습니다

@RestController 이전에는 @Controller와 메서드 선언부에 @ResponseBody를 이용해서 동일한 결과를 만들 수 있습니다

@RestController는 JSP와 달리 순수한 데이터를 반환하는 형태이므로 다양한 포맷의 데이터를 전송할 수 있습니다. 주로 많이 사용하는 형태는 일반 문자열이나 JSON, XML 등을 사용합니다

REST 방식으로 호출하는 경우는 화면 자체가 아니라 데이터 자체를 전송하는 방식으로 처리

REST 방식에서는 URL 내에 최대한 많은 정보를 담으려고 노력

REST 방식에서는 URL 자체에 데이터를 식별할 수 있는 정보들을 표현하는 경우가 많 으므로 다양한 방식으로 @PathVariable이 사용

REST 방식을 가장 많이 사용하는 형태는 역시 브라우저나 모바일 App 등에서 Ajax를 이용해서 호출하는 것입니다

3.json

JSON은 'JavaScript Object Notation의 약어로 구조가 있는 데이터를 { }로 묶고 ’키와 값으로 구성하는 경량의 데이터 포맷입니다

프로그래밍 언어에서 말하는 객체(Object)들의 구조는 { }를 이용해서 다음과 같이 표현할 수 있다

구조를 표현한 문자열은 프로그래밍 언어에 관계 없이 사용할 수 있기 때문에 XML과 더불어 가장 많이 사용되는 데이터의 표현 방식입니다.

https://mvnrepository.com/artifact/com.fasterxml.jackson.core/jackson-databind

1. REST(REpresentational State Transfer) : 

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

그래서 이러한 제약조건을 모두 지켜야 REST를 따른다고 말할수 있다.

그리고 REST는 하이브리드 아키텍쳐 스타일이라고로 불린다 왜냐하면 아키텍쳐 스타일이면서 아키텍쳐 스타일의 집합이기때문

그래서 6가지의 아키텍쳐 스타일로 이루어져있음

1. Uniform interface (유니폼 인터페이스) : 이것도 하나의 스타일이다. 이 안에 제약조건을 보자

 - Uniform interface의 4가지 제약조건

1) identification of resources

  > Resource가 URI 로 식별되면 된다라는것

2) manipulation of resources through representations 

  > representations 전송을 통해서 resources를 조작해야한다. 리소스를 만들거나,업데이트,.삭제등을 할때 http메시지에다가

표현을 담아서 전송을하면된다는것 

  > representations이란 HTTP 메소드의 PUT, GET, DELTE 등을 말한다.

3) self-descriptive messages (지키기 어렵다)

메시지는 스스로를 설명해야한다는것,메시지를 봤을때 메시지의 내용으로 온전히 다해석이 되야함

  Ex) 

  (1) GET / HTTP /1.1

  은 self-descriptive 한가? No, 목적지가 빠져있기 때문에 안된다. 

  -> 다음과 같이 수정 필요 

      GET / HTTP /1.1

  Host: www.test.co.kr

  은 self-descriptive 하다.

  (2) HTTP/1.1 200 OK

      [ {"op": "remove", "path": "a/b/c/" }

  은 self-descriptive한가 ? No, Client가 해석을 못한다.

  -> 다음과 같이 수정 필요 

  HTTP/1.1 200 OK

  Content-Type: application/json-path+json  

      [ {"op": "remove", "path": "a/b/c/" } 

  은 self-descriptive한다. 

  이유는 Content-Type의 application/json-path+json 명세를 통해서 

  body 내용을 해석 할수 있기 때문이다.

4) hypermedia as the engine of application state(HATEOAS) (지키기 어렵다)

application의 상태는 Hyperlink를 이용해서 전이 되어야한다.

 > HATEOAS는 다음 그림과 같이 링크를 통해서 상태 전이가 되어야 한다는 것을 말한다.

  Ex)

  (1) HTML은 HATEOAS를 만족한다. a 태그를 통해서 Hyperlink를 사용한 상태 전이가 가능하다.

HTTP/1.1 200 OK

Content-Type: text/html

<html>

<head></head>

<body><a href="/test">test</a></body>

<html>

  

  (2) JSON은 HTTP의 Link header를 통해서 HATEOAS를 만족시킬 수 있다.

HTTP/1.1 200 OK

Content-Type: application/json

Link: </article/1>; rel="previous",

  </article/3>; rel="next";

{

"title": "The second article",

"contents": "blah blah.."

}

      

 

4. 왜 uniform interface가 필요한 이유

  - 독집적 진화를 위해서

    1) 서버와 클라이언트가 각각 독립적으로 진화한다. 

    2) 서버의 기능이 변경되어도 클라이언트를 업데이트할 필요가 없다. 

    3) REST를 만들게 된계기 : "How do i improve HTTP without breaking the web"

내가 HTTP를 고치면 웹이 동작안할거같은데 어떻게 해야하나하는 고민에서 나온것

5. REST를 사용한 사례

  - 웹

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

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

    3) HTTP 명세가 변경되어도 웹은 잘 동작한다. 2.0등등

    4) HTML 명세가 병경되어도 웹은 잘 동작한다. 5.0 5.1등등

물론 깨질수는 있는데 동작은한다.

2. REST API란: 하이퍼 텍스트를 포함한 self-descriptive한 메시지의 uniform interface를 통해

리소스에 접근하는 api

- REST 아키텍쳐 스타일을 따르는 메시지를 통해 Resource에 접근하는 API

self-descriptive: 서버나 클라이언트가 변경되더라도 오고가는 메시지는 언제나 self-descriptive 하므로 언제나 해석이 가능하다.

REST API 목적??

  - REST API의 목적은 핵심 컨텐츠 및 기능을 외부 사이트에서 활용할 수 있도록 제공되는 인터페이스입니다.

8. 정리 

 1)오늘날 대부분의 "REST API"는 사실 REST를 따르지 않고 있다. 

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

 3)REST는 긴 시간에 걸처 진화하는 웹 애플리케이션을 위한 것이다. 

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

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

   - self-descriptive는 cumstom media type이나 profile link relation

     등으로 만족시킬수있다. 

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

2. RESTful API란 : 

- REST API에 대한 비공식 적인 가이드가 RESTfull API이다.

.

REST의 기본 원칙을 성실히 지킨 서비스 디자인은 “RESTful 하다.” 라고 흔히 표현합니다

https://brainbackdoor.tistory.com/53

https://spoqa.github.io/2012/02/27/rest-introduction.html