Rest

 

Respresentational

State

Transfer

 

컴퓨터 시스템 간의 상호교환성 방법

 

WEB

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

 

표현방식 html

식별자 url

전송 방법 http

 

API

 

xml-rpc (1998)

by microsoft

->soft 개명

 

salesforce API (2000)

-> 짱 복잡...

 

flickr API (2004)

SOAP

REST <- 짱 짧음, 단순, 쉽다

 

2010 에는 salesforce 도  rest 씀

 

CMIS

cms 를 위한 표준

rest 바인딩 지원 

-> rest를 만든 사람(로이필딩)은 cmis 에 rest가 없다고 이야기함

 

microsoft Rest Api guidelines (2016)

https://{service}/{collection}/{id}

GET / PUT / DELETE / POST / PATCH / OPTIONS

-> rest 만든 사람(로이필딩)은 내 rest 아니라고 이야기함

 

REST API

rest api 아키텍처를 따르는 api

 

REST

-> 분산 하이퍼미디어 시스템(web 같은)을 위한 아키텍쳐 스타일

 

아키텍쳐 스타일

-> 제약조건의 집합

 

rest를 구성하는 스타일

- client-server

- stateless

- cache

- uniform interface

- layered system

- code-on-demand (optional) <- 서버를 코드를 클라이언트로 보내서 실행할 수 잇어야함 (js 같은 거)

 

 

uniform interface

-> 서버와 클라이언트가 독립적으로 진화하기 위해

-> 서버의 기능이 변경되어도 클라이언트를 업데이트할 필요가 없음

 

- 리소스가 url로 식별되면 좋음

- 리소스를 만들거나 삭제하거나 할 때 http 메세지에 표현을 담아서 전송하면 좋음

- 메세지는 스스로를 설명해야함

-> host 에 도메인을 넣어주던가, 응답 메세지에 컨텐츠 타입을 넣어주기

아래 사진 보면 content-type 에 application/json-patch+json 이라고 명세했는데, 이러면 클라이언트 개발자는 해당 content-type 명세 찾아가서 보면 됨

 

- 애플리케이션의 상태는 hyperlink를 이용해 전이되어야함 - hateoas

-> a 링크 같은경우 a링크를 통해서 href의 링크를 들어갈수 있는 점이 명확함

 

 

웹(Rest를 정말 잘 지킴)

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

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

- http 명세가 변경되어도 웹은 잘 동작함 - 2.0 으로 업데이트해도 잘 됨

- html 명세가 변경되어도 웹은 잘 동작함 - 5.0 나와도 잘 됨

 

 

나쁜 예

모바일 강제 업데이트

-> 서버가 변경되엇는데 클라이언트가 받쳐주지 못하는 경우

-> 웹에서는 이런 일이 거의 없음.. 

 

 

이처럼 웹은 상호 운용성에 대한 집착이 있음 - interoperability

- referer 오타지만 안 고침

- charset 잘못 지은 이름이지만 안 고침

- http 상태코드 416 포기함 

- http/0.9 아직도 지원함

 

 

 

로이필딩 : RestApi 는 꼭 지켜야 됨...

시스템 전체를 통제할 수 있다고 생각하거나, 진화에 관심이 없다면 rest에 대해 따지느라 시간을 낭비하지마세요

 

 

 

 

 

 

 

 

출처 : https://youtu.be/RP_f5dMoHFc?si=IgrFp3hAuA3_ZQzl

 

rest는 그냥 웹을 하려면 반드시 써야하는 업계 표준 느낌