[WEB] REST, RESTful, RESTful API

[미리 스포] 코세라 완강 했습니다 ^^ 경축 !!!!!

​

레퍼런스는 2개를 참고했고, 맨 아래 쓰도록 하겠습니다.

 

REST ?
Representational State Transfer

그.. 요즘 공고를 보면 RESTful API 사용 가능자, 설계 가능자( 경력직) 에 이런게 보이는데..

진정한 의미의 RESTful API를 설계하는것은 사실상 거의 불가능하다고 생각됩니다. ( 유튜브 REST 이대로 어쩌고~) 그걸 보고나서 생각이 들었습니다. HATEOS, self-descriptive한 RESTful API 를 설계하는 사람이 진짜 있을까요? media-type 같은것은 IANA에 다 정의를 해야한다고 하는데.. 마이크로소프트도 REST아닌데 RESTful이라고 한다고 합니다. (반박은 빌게이츠에게만 받겠습니다)

​

일단 이게 기존에 SOAP보다 더 간편하고, 경량화 되어있어서 REST를 사용합니다.

뭘 쓰다가 이게 나온지는 알아야 하잖아요? 굿

​

REST는 뭘까요?

resource가 어떻게 정의되고, 표현되는지 나타낸 네트워크 제약조건들의 집합입니다.

분산 하이퍼 미디어 시스템(ex WEB) 을 위한 아키텍처 스타일 이다. (공식문서 정의)

-> 아키텍처 스타일은 제약조건의 집합을 말합니다.

​

server가 client랑 http 프로토콜을 이용해서 JSON document를 주고받는것을 의미합니다.

물론 꼭 HTTP나 JSON을 이용해야 하는 것은 아닙니다.

논문에는 제약조건과 아키텍처 엘리먼트에 대해서 나와있지만, 이것이 의무적으로 지켜야 하는 조건은 아닙니다.

REST는 또한 어떤 국가적 표준 이런게 없습니다. 조금 이상하게 쓰고 자기네가 REST라고 우기면 그런갑다 하게 됩니다.

​

Restful -> Rest방식을 따르는것

Restful API -> Rest방식을 따라서 API를 설계한 것

​

RESTful 하다 라고 불리려면, REST는 특정 제한조건들이 있습니다.

이것을 따라야 RESTful 하다고 할 수 있습니다. 일단 이게 왜 생겼는가? 에 대한 의문이 있습니다.

​

-> Web을 성공적으로 만들어주는 Web의 특징들을 좀 이용하려고 만들어졌습니다.

HTTP Protocol GET, POST 이외에 PUT, DELETE등을 이용할 수 있습니다.

​

이 Verb들은 CRUD와 비슷하게 매칭할 수 있습니다.

(공식적인 매칭이 아닙니다. 사회적으로 대부분 이렇게 쓰이기에 비슷하다고 할 수 있습니다)

(회사별로 다를 수 있습니다)

보편적으로

GET -> READ

POST -> CREATE

PUT -> UPDATE (전체)

DELETE -> DELETE

PATCH -> UPDATE(일부)

​

이런식으로 사용된다고 합니다.

​

REST의 제약조건에 앞서서, 3가지 컨셉에 대해서 알아보겠습니다.

1. Verb(행위), 제한이 있습니다. GET,PUT,POST,DELETE, ( PATCH 가끔)

2. Representations(표현), 제한이 있습니다. XML, JSON같은 파일들로 표현해야 합니다.

3. Resource(자원), 제한이 없습니다. http://www.naver.com/dishes/123 이런식으로 표현할 수 있습니다.

(collection과 document로 나뉜다고 하는데, collection은 dishes, document는 123입니다 이런 명명법에는 추천하는 명명법이 있다고 합니다)

​

REST의 제약조건들

실제 논문을 참고로 했습니다

1. Client-Server

클라이언트-서버 아키텍처 디자인을 따라야 합니다.

UI (클라이언트) 관심사를 Storage (서버)와 분리해서 멀티 플랫폼에 UI 이식성을 높이고, 서버 컴포넌트를 단순화 해서 확장성을 증가시킬 수 있습니다.

​

클라이언트와 서버가 독립적으로 된다면, 하나의 서버에 여러 다른 종류의 클라이언트에도 같은 반응을 할 것입니다.

​

2. Stateless

client-server interaction에서 추가된 제약조건 입니다.

c-s간의 커뮤니케이션은 state가 없어야 합니다.

​

클라이언트가 서버에게 요청을 할 때 필요한 정보들을 모두 포함해야 합니다.

WHY? 서버에서는 어떠한 정보라도 request 이외의 정보로부터 값을 얻으면 안되기 때문입니다.

따라서 모든 session state는 client에서 유지되어야 합니다.

​

이렇게하면 뭐가 좋을까요?

visiblity : 모니터링 시스템은 request의 전체 특징을 알아낼때, 요청된 data만으로 충분히 알아낼 수 있습니다.

왜냐면 request에 모든걸 담았기 때문이죠. 다른것을 보지 않아도 됩니다.

​

reliability : 요청간의 store state를 가지고 있지 않아서, 서버는 빠르게 자원을 해제하고 더 나아가 구현을 단순화 시킵니다.

(서버가 request만 처리하고 그 이상의 자원 사용은 처리해줄 필요가 없기 때문입니다)

​

그럼 단점은 없을까요?

아닙니다.

network performance를 저해합니다. 이게 좀 중요한데, 왜 저해할까요?

state를 저장하지 않으니까 했던 요청을 어디 가둬둘곳이 없습니다. 이 요청들이 server-client간의 interact overhead를 증가시킵니다.

​

또한 client가 app의 state를 가지고 있기때문에, 서버가 client를 제어할 수 없습니다.

​

이러한 단점을 해결하기 위해 또 뭐가 하나 더 등장합니다.

​

3. Cache

네트워크의 효율성을 증가시키려면 캐시 제약조건을 걸어야 합니다.

ccss(client cache stateless server)

request에 응답하는 데이터는 명시적으로나 암시적으로나 cacheable, non-cacheable을 표시해야 합니다.

fetch에서 보면 default는 non-cacheable 입니다.

만약에 cacheable이면 나중에 client cache는 같은 데이터를 요청했을때, 캐시를 대신 쓸 권한이 생기게 됩니다.

​

이 Cache의 장점은 무엇일까요?

2번의 단점을 커버할수도 있고,

여러 interaction에서 얻어지는 평균 latency(주고 받는 시간)을 낮춰주니까 사용자가 체감하는 성능이 증가됩니다.

또한 반복적인 interaction을 제거해주기 때문에, 효율성도 좋아집니다.

scalability가 좋아진다고도 하는데, 캐시를 써서 어떤 확장성을 얻는다는걸까요.. 이건 아직 체감이 잘 안됩니다.

​

아!

캐시를 쓰는데 단점이 있다고 합니다.

파도파도 미담밖에 없을것 같은 캐시에 무슨 단점이 있을까요?

​

reliability 신뢰성 이 떨어진다고 합니다.

이게 무슨말이냐 하면.. 만약 캐시에 값이 있다고 합시다.

그런데 서버에서 받아온 값과 cache에 있는 값이 다를 수 있습니다. (stale data)라고 하는데

react에서 비동기 처리 할때도 stale state때문에 문제가 있는 경우가 있었는데, 여기서도 말썽을 일으킵니다.

​

예시가 뭐가 있을까 생각해봤습니다.

물론 이렇게 하는 정신나간 사람은 없겠지만, 서버의 시간을 받아오는 코드가 있다고 합시다.

이것을 RESTful하게 받아서 cache에 넣었습니다.

10분후에 또 요청을 했는데, cache에 있는 값을 쓴다면 될까요?

안됩니다. 애초에 캐시에 담으면 안되는거지만.. 예시입니다!!

이러면 캐시의 값과 서버에서 받아온 값이 달라서 문제가 생기겠죠? 따라서 신뢰성이 떨어진다고 볼 수 있습니다.

​

​

4. Uniform inteface

REST와 다른 아키텍처 style을 구분하는 핵심 특징입니다.

​

보통 다들 1,2,3번 규칙들은 잘 지킵니다. 아니, 잘 지켜집니다. 뭘 딱히 설정 안해도 대부분 저런 조건에서 돌아가기 때문입니다.

하지만 여기부터는 조금 다릅니다. 저도 처음 알게 됐습니다.

이건 위키피디아를 참고했습니다.

​

4-1. 요청에서 자원을 식별해야 합니다.

URI를 이용해서 어떤 자원을 요청했는지 식별할 수 있어야 합니다.

그럼 URI는 뭘까요? URL은 아시죠? 주소를 나타내잖아요? URL이 URI의 부분집합 입니다. 더 하위에 있습니다.

URI는 자원이 어디있는지 나타내는 '유일한'(unique) 주소입니다. JSON파일같은것을 보지 않고도 이걸로 어떤 리소스를 가리키는건지 알 수 있어야 합니다. (dish폴더의 13번 dish라고 알려줍니다)

​

4-2. representation을 통해서 자원을 조작할 수 있어야 합니다.

JSON파일을 보낼때 충분한 메타데이터가 포함되어 있으면, 그 정보들로 충분히 수정하고 삭제할 수 있습니다.

body에 담고 POST로 보내고 하면, body에 담긴걸 create 하겠죠?

​

메타데이터는 뭘까요? -> 정보를 설명하는 정보를 말합니다.

음.. 어떤 구조체를 사용하는데, 그 구조체에 대한 설명을 해주는 구조체 라고 할까요? 여러분들이 와닿을지 모르겠네요..

​

DELETE https://www.mypage.com/dishes/13

어떤가요? dishes에 있는 id 13번을 삭제해야할것 같지 않나요?

​

--여기부터는 유튜브 REST 이대로 괜찮은가? 라는 유튜브에서 좀 더 설명을 많이 들었습니다.

또한 여기부터는 지키기가 힘든 부분들입니다. 따라서 엄밀한 RESTful API가 되기 힘든 부분이기도 합니다.

​

4-3. Self-descriptive message.

자기 자신을 설명할 수 있는 메세지여야 한다고 합니다.

​

이건 저도 마찬가지인데,

fetch( URL , { headers : "Content-Type : application/json"} 이렇게 하면 안된다고 합니다.

사실 이렇게 하면서 다들 RESTful 하게 했다고 하는데 이건 Uniform Interface의 규칙을 지키지 않았다고 합니다.

왜냐면 저렇게 쓰면 HTTP명세에 media type은 IANA에 등록되어있으므로, IANA에서 application/json의 설명을 찾습니다

https://www.ietf.org/rfc/rfc4627.txt

 

여기서 JSON을 파싱을 하지만, JSON 내부의 키와 밸류는 무슨 의미를 가지는지 모릅니다.

[ { "good" : "true", "path" : "/a/b/c"} ]

good이 true고, path가 어딘지는 아는데 이게 뭔 말인가는 해석할 수 없습니다.

하지만

application/json-company-rule+json

으로 만들면 json-company-rule의 specification을 보고나서 이해할 수 있는겁니다.

​

그러면 왜 일반적으로 저렇게까지는 하지 않는가?

제가 직접 들어가봤습니다

IANA에 Media Type을 등록해주면 된다고 합니다.

​

뭡니까? 하나 등록할때마다 RFC 다 읽고 이해하고 남겨야하고, 굉장히 복잡합니다.

즉 현실적으로 좀 괴리감이 있습니다.

​

4-4 Hypermedia as the engine of application state (HATEOAS)

​

REST 클라이언트가 서버에서 주는 링크들을 타고 동적으로 다른 리소스들에 접근할 수 있어야 합니다.

HTML의 <a href="~~~"> 이거 생각하면 될 것 같습니다.

​

a링크를 누르면 그냥 다른 페이지로 넘어갑니다.

하지만 JSON파일은 어떻게 다른 페이지로 넘어갈까요?

Link라는 헤더를 통해서 해야한다고 합니다

 

HTTP/1.1 200 OK
Content-Type : application/json,
Link : </articles/1>; rel = "next",
       </articles/2>; rel = "prev",

{
   "title" = "abc",
   "page" = 13,
}

이러한 조건을 만족하는 API를 Restful한 API라고 합니다.

​

그러면 이렇게 하면 좋은건 뭘까요?

Uniform Interface를 사용하게되면 Server와 Client가 각각 독립적인 진화를 할 수 있습니다.

서버의 기능이 변경되어도, client는 그냥 표준만 잘 지켜서 보내면 그에 맞는 응답을 해줄 수 있습니다.

​

웹은 독립적 진화를 하는걸까요?

​

웹 브라우저(서버), 웹 페이지(클라이언트) 의 관계를 생각해봅시다.

구글 크롬은 현재 90버전이 넘었습니다. 하지만 계속 업데이트를 한다고, 웹 페이지가 안나오나요?

지원하지 않는 기능은 있을지언정 페이지가 안나오지는 않습니다.

또한 우리가 Firefox를 쓴다고 해서 웹 페이지가 나오지 않나요? 아닙니다.

​

이 웹의 예시가 독립적 진화의 예시입니다.

​

그러면 REST가 실제로 도움을 주었는가? 할 수 있습니다

​

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

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

- Host 헤더 추가 (Self-descriptive를 위해)

- 길이 제한을 다루는 방법이 명시 (414 URI TOO Long)

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

- 기타 HTTP와 URI에 많은 영향을 줌

- Roy Fielding이 HTTP와 URI 명세의 저자 중 한명이라서 연관이 있음

(이것은 그런 REST API 이대로 괜찮은가? 라는 유튜브를 참조했습니다)

​

또한 독립적인 성장을 위해서,

Media Type 등록시에

이렇게 다른것들과 잘 호환이 되는지도 검사를 합니다.

즉 어떠한 client에서 요청이 오더라도 다 가능한가? 도 중요한 요소라는겁니다.

​

​

​

이렇게 REST에 대해서 알아보았습니다.

​

이걸 쓰는데 굉장히 많은 자료들을 보았는데.. 다 짬뽕하고 거를거 걸러서 이정도인듯 합니다.

​

현업에서 RESTful API를 사용하시는 분들이라면 어떻게 쓰는지 댓글 남겨주시면 더 좋을것 같습니다.

RESTful API 설계 가능자.. 쉽지 않군요. 과연 다 알지도 의문입니다.

​

REST : client,server간의 데이터 전송을 위한 여러가지 제약조건들 (웹을 위한 여러가지 제약조건의 집합들)

RESTful : REST의 조건을 만족했다. RESTful 하다

RESTful API 설계 : REST의 조건을 지키는 API를 직접 만든다.

​

이정도로 받아들였고, 사실 아직 막 와닿지 않습니다. 텍스트로 배우는 느낌이라, 앞으로 적용할 일이 있겠지요..

​

감사합니다^^

​

다음 포스팅은 react-thunk에서 REST방식을 이용해서 값을 불러오고, reducer에 dispatch해서 store를 업데이트 해보겠습니다.

​

​

​

REFERENCE

---

https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

Fielding Dissertation: CHAPTER 5: Representational State Transfer (REST)

 

https://en.wikipedia.org/wiki/Representational_state_transfer

Representational state transfer - Wikipedia

 

https://blog.ndepend.com/rest-vs-restful/

REST vs RESTful: The Difference - NDepend Blog

 

https://restfulapi.net/

REST API Tutorial

 

https://youtu.be/RP_f5dMoHFc