일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- 라우팅프로토콜
- 스노트
- Cosmos
- programmers
- 컨테이너
- 리눅스
- 데이터베이스
- MySQL
- 프로그래머스
- db
- 코딩테스트
- Snort Rule
- docker
- Router
- 라우팅
- 트레바리
- Python
- Linux
- Container
- snort
- OSI7계층
- database
- Routing
- osi7layer
- 도커
- 코딩 테스트
- TDD
- coding test
- 라우터
- 스노트 룰
- Today
- Total
Simple is IT, 누구나 보고 누구나 깨닫는 IT
REST는 무엇일까? 본문
REST의 정의/개념
REST는 어떤 특징을 가지고 있을까요?
그렇담 RESTAPI / RESTful은 뭐에요?
REST의 정의
: www와 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식이에요.
(약자는 Representation State Transfer입니다 !)
구체적으로 자원을 이름으로 구분해 해당 자원의 상태와 정보를 주고받는 모든 것을 의미하죠.
'자원의 이름', '상태와 정보의 주고받음'이란?
자원의 이름 : 자원을 표현하기위한 이름을 말해요.
ex) DB에서의 고객들을 자원이라고 한다면 그러한 표현은 'customer'로 할 수 있겠죠 !
상태/정보 전달 : 누군가가 요청하는 시점에서 자원의 상태 및 정보를 전달하는 것을 말해요.
ex) 일반적으로 XML, HTTP, JSON 등의 형태로 전달이 돼요.
이해하기 어려워요.. 정확한 개념이 뭐에요?
: HTTP URI를 통해 자원을 명시, HTTP Method를 통해 자원에 대한 CRUD Operation을 적용을 의미하죠.
REST. 정말 간단한 정도로 이해하고 싶다면 HTTP URI를 이용해 작업하는 일을 말해요 !
여기서 CRUD Operation은 무엇일까요?
Create | 생성 (POST) |
Read | 조회 (GET) |
Update | 수정 (PUT) |
Delete | 삭제 (DELETE) |
Head | header 정보 조회(HEAD) |
REST의 특징
REST가 필요한 데에는 이유가 있겠지요.
1. Application의 분리 또는 통합을 위해
2. 다양한 클라이언트의 등장
3. 최근의 서버 프로그램은 다양한 브라우저, 안드로이드, 아이폰의 IOS와 같은 모바일 장치에서도 통신을 할 수 있어야해요.
이런 REST에겐 적용되어야하는 조건이 있어요 ! (깐깐)
- Server/Client 구조여야만 해요.
- 무상태(Stateless)를 원해요.
- 캐시처리가능(Cacheable)이 필요해요.
- 계층화(Layered System)
- Code-On-Demand도 있지만 무조건은 아니에요.
- 인터페이스의 일관성(Uniform Interface)를 요구해요.
▼ 각 조건에 대해 의아하신 분 또는 구체적인 설명을 원한다면 아래
- Server/Client : 일관적인 인터페이스로 분리되어야 해요.
- 무상태(Stateless) : 각 요청 간 클라이언트의 콘텍스트가 서버에 저장되어서는 안돼요.
- 캐시처리가능(Cacheable) : WWW에서와 같이 클라이언트는 응답을 캐싱할 수 있어야 해요.
-> 잘 관리되는 캐싱은 클라이언트-서버 간 상호작용을 부분적으로 또는 완전하게 제거하여 scalability와 성능을 향상시켜요. - 계층화(Layerd System) : 클라이언트는 보통 대상 서버에 직접 연결되었는지, 또는 중간 서버를 통해 연결되었는지를 알 수 없어요. 중간 서버는 로드밸런싱 기능이나 공유 캐시 기능을 제공함으로써 시스템 규모 확장성을 향상시키는 데 유용해요.
- Code-On-Demand(Optional) : 자바 애플릿이나 자바스크립트의 제공을 통해 서버가 클라이언트가 실행시킬 수 있는 로직을 전송하여 기능을 확장시킬 수 있어요.
- 인터페이스 일관성(Uniform Interface) : 아키텍처를 단순화시키고 작은 단위로 분리(decouple)함으로써 클라이언트-서버의 각 파트가 독립적으로 개선될 수 있도록 해준답니다.
REST의 구성 요소
- 자원(Resource) : URI
- 행위(Verb) : HTTP Method
- 자원의 표현(Representation of Resource) : 요청에 대한 적절한 응답(JSON, XML 등)
이렇게 깐깐하고 사용하기도 어려워 보이는 REST는 HTTP 프로토콜을 그대로 활용하기 때문에 웹의 장점을 마구마구 활용 가능하답니다.
그렇담 REST API와 RESTful은?
API(Application Programming Interface)
: 데이터와 기능의 집합을 제공해 컴퓨터 프로그램 간 상호작용을 촉진하고, 서로의 정보 교환이 가능해요.
정의
: 간단합니다. 그저 REST 기반의 API를 말해요. (OPEN API, 마이크로서비스 등은 대부분 사용)
- REST 기반으로 시스템을 분산하면 확장성과 재사용성을 높여 유지보수 및 운용을 편리하게 할 수 있어요.
- HTTP 표준을 기반으로 구현하니 HTTP를 지원하는 모든 언어들로 Server, Client를 구현할 수 있어요.
▼ 추가로 REST API에 대한 설계 규칙이 있어요 !
1. 슬래시(/)는 계층 관계를 나타내는 곳에 사용해요.
http://blog.naver.com/hyun0524e
2. URI 마지막 문자로 슬래시(/)를 포함하지 않아요.
ex) http://blog.naver.com/hyun0524e/ (x)
ex) http://blog.naver.com/hyun0524e (o)
3. 하이픈(-)은 URI의 가독성을 높이는데 사용해요.
4. 언더바(_)는 URI에 사용하지 않아요.
5. URI 경로에는 소문자가 적합해요. (대소문자에 따라 다른 리소스로 인식하기 때문이죠)
RFC 3986 is the URI (Unified Resource Identifier) Syntax document
6. 파일확장자는 URI에 포함시키지 않아요.
ex) http://blog.naver.com/hyun0524e/test/example.jpg (x)
ex) GET / test/example HTTP/1.1 Host:blog.naver.com Accept: image/jpg (o)
7. 리소스 간의 관계를 표현하는 방법이 있어요.
/리소스명/리소스ID/관계있는 다른 리소스명
ex) GET : /users/{userid}/devices
RESTful
: REST 아키텍처를 구현한 웹 서비스를 나타내는 용어를 말해요 !
이건 누가 만들었다 하기보단 자연스레 생긴 용어라 보시면 될 것 같아요. (오우 RESTful하다 ~)
REST. 생각보다 시간을 많이 들여가며 이해했지만 그만큼 여러분들께서 원하는 답을 얻으셨으면 좋겠네요. 감사합니다 !
'Simple is IT > Network' 카테고리의 다른 글
OpenDayLight(SDN Controller, Openflow) Flow Rules 추가 (0) | 2020.04.27 |
---|---|
OpenDayLight (SDN Controller, Openflow) (0) | 2020.04.27 |
Mininet!! SDN(Software Defined Networking, Openflow) 설정 (1) | 2020.04.27 |
SSL Strip (0) | 2020.04.27 |
Firewall_NAT(Network Address Translation) (0) | 2020.04.26 |