REST?
-
역사
- 2000년대 Roy Fielding 박사의 논문에 처음 인용됨.
Architectural Styles and the Design of Network-based Software Architectures
-
초간단 요약
→ 웹은 왜 이렇게 성공했고, 왜 이렇게 대규모 시스템이 성립이 된건지 소프트웨어 관점에서 분석하고 하나의 아키텍처 스타일로 정리했는데 이를 REST라 이름 지었다.
-
라이브러리를 개발하면서 다른 사람과 작업을 공유하고 싶음. ( 공유의 필요성 )
- RPC 데몬을 개발. Remote Procedure Call ( 주로 유닉스 사용)
- 보안 ,리소스 사용 취약함.
- RPC 데몬을 개발. Remote Procedure Call ( 주로 유닉스 사용)
-
문제점 해결을 하는 동안 프로그래밍 언어, OS 에 상관 없이 해결 하도록 시도.
- CORBA의 등장!
- 무겁고 비쌈. ( 2000년대 1억 )
- RMI - 자바의 RPC 데몬
- 사내 네트워크에서는 무리 없지만, 방화벽 문제가 생긴다.
- 기본적 방화벽은 http만 열어줌
- CORBA의 등장!
-
그래서 HTTP를 쓰자!
- 초기
-
SOAP
- XML + HTTP 를 결한한 웹 서비스
- Service-Oriented Architecture → 서비스지향 구조
- 서비스를 자유자재로 정의할 수 있다 == 복잡하다.
-
ROA의 등장.
- Resource-Oriented Architecture → 리스소 기반 구조
- HTTP의 기본 메소드는 CURD와 매핑이 된다
-
- 초기
-
상태값을 전달한다?
-
결과값에 인터넷에서 발생할 수 있는 상태값을 전달한다.
→ 상태값 코드별로 대응이 가능하다.
→ 상태값 코드만 안다면 누구나 쉽게 이해할 수 있다.
-
State code 일부값
- 200 성공
- 404 Not Found
- 500 내부 서버 오류
→ 결과적으로 REST 구조는 HTTP 프로토콜에서 제공해주는 메커니즘을 그대로 활용한다.
-
-
REST의 장점?
- 쉬운 사용
- 서버가 어떻게 돌아가는지 알 필요가 없고 해당 URI와 메소드 자체만 독립적으로 이해하면 됨.
- 클라이언트와 서버의 명확한 분리
- HTTP의 Stateless 한 특징
- 다양한 플랫폼에서 원하는 서비스를 빠르고 쉽개 배포 가능.
- HTTP header 와 body의 구조
- 헤더에 url 처리 메소드 명시
- body에는 필요한 데이터로 구성되어 다양한 언어를 사용할 수 있다.
- 웹 친화적
- 방화벽 문제를 해결 가능
- 캐싱
- 개발자 직관적
- 컨텐츠 협상
- 클라이언트가 영문 → 서버가 한글이여도 컨텐츠 협상을 통해 다르게 응답할 수 있다.
- 쉬운 사용
-
REST의 단점
- 메소드의 형태가 제한적이다.
- 표준이 없다
- 관리의 어려움과 공식화된 API 디자인 가이드가 없다.
구성 요소
-
Resource
→ 유일한 ID를 가지는 Resource가 서버에 존재.
— id는 일반적으로 url을 사용한다.
→ 클라이언트 → 서버 자원의 상태를 조작하기 위해 요청을 보냄.
-
Method
→ 자원을 조작할 수 있는 것.
-
Get
→ 서버에게 Resource를 보내도록 요청.
→ 사용
- 자원을 읽음.
-
Post
→ 서버에 데이터를 보내기 위함.
→ 사용 :
- 업데이트
- Put과의 차이는 put은 서버 자원에 데이터를 저장 시기키 위함.
- Post는 데이터를 보내기 위한 용도
-
Put
→ 자원의 전체 내용을 교체할 때
→ 사용 :
- 모든 파라미터 (데이터의) 자원이 교체 되어야한다.
-
Delete
→ 자원을 삭제를 하도록 요청
→ 서버가 무시할 수 있다.
→ 항상 보장 되지 않음.
-
Head
→ Get과 동일하지만 서버에서 body를 주지 않음
→ 사용
- 자원이 존재하는지 확인
- 리소스 수정 되어 있는지 확인 ( context-length )
-
Connect
→ http connecct 방법.
→ http 프록시 서버에 tcp 연결을 원하는 대상으로 전달하도록 요청.
→ 사용 :
- 최초의 연결만 http 연결이고 이후에는 tcp 사용하여 연결함.
-
Options
→ 타겟 서버의 지원 가능한 method 확인.
-
Trace
→ 클라이언트 → Request Packet → (방화벽, Proxy Server, Gateway) → 서버
→ 이 진행 상황중 packet의 변조가 일어날 수 있다.
→ 원본 데이터와 서버 도착 데이터를 서버 응답 body를 통해 확인할 수 있다.
→ 사용
- 보안 취약점으로 인해 사용 중지 권장.
-
Patch
→ put과 유사하지만 부분을 바꿀 때 사용한다.
→ 사용 :
- 전체를 바꾸는 게 아니라 부분을 바꿀 때 사용.
-
-
Representation of Resource
- 자원을 이름으로 구분하여 해당 자원의 상태를 주고 받는 모든 것.
-
URI
- Uniform Resource Identifier
- 자원의 주소를 명시한다.
RESTFUL
REST의 제약에 따르고 있고, REST다운 것을 말한다.
필요 최소한으로 지켜야할 5가지 규칙
-
API의 ENDPOINT 가 오직 한개인가?
- 오직 한개의 URL로 fix
- 실제 자원에 대한 정보는 body에 전송 하도록 구현
-
모든 방식은 POST 방식으로만 요청하는가?
- POST , PUT, GET, DELETE 메소드를 사용해라
- 잘한 것
- POST /url
- PUT /url
- GET /url
- DELETE /url
- 잘못된 것
- POST /url?cmd=insert
- POST /url?cmd=update
- POST /url?cmd=select
- POST /url?cmd=delete
-
응답에 대한 메타데이터를 BODY에 포함하는가?
- 메타 데이터는 Header
- Body는 오로지 리소스의 순수한데이터만!
-
URL에 동사(VERB)가 포함되어 있는가?
- URL의 이름은 주소값 → 명사적인 특징을 가진다
- 동사적 틍직을 가지면 혼돈이 올 수 있다.
-
URL에 RPC 호출 메서드 명령이 있는가?
- URL에 PRC (Remote Procedure Call )사용하지 마라.
'html' 카테고리의 다른 글
[Google SEO] 구글 SEO 기초중의 기초 (0) | 2019.10.31 |
---|---|
[HTML / CSS] 브라우저 기본값 초기화(reset) 개념 정리 (0) | 2019.10.29 |
[HTML5] 시맨틱태그 정리 (0) | 2019.10.24 |