REST 이해하기
"Representational State Transfer"
자원(Resource)의 표현 및 표출(Representation)에 의해 상태(State)를 전달하는 것
HTTP 프로토콜을 사용으로 웹의 장점을 최대한 활용할 수 있는 아키텍처
HTTP URI(Uniform Resource Identifier)으로 자원을 명시
HTTP Method(POST, GET, PUT, DELETE)로 자원에 대한 CRUD Operation을 적용
CURD
- C : Create : 생성(POST)
- R : Read : 조회(GET)
- U : Update : 수정(PUT)
- D : Delete : 삭제(DELETE)
- HEAD : Header 정보조회(HEAD)
REST 장/단점
장점
- HTTP 프로토콜을 사용하여 REST API 사용을 위한 별도의 인프라 구축 필요 없음
- HTTP 프로토콜의 표준을 최대한 활용하여 장점을 활용할 수 있음
- HTTP 프로토콜 표준을 따르는 모든 플랫폼에서 사용 가능
- REST API 메시지가 의도하는 바를 명확하게 표현할 수 있음
- 서버와 클라이언트의 역할 분리
단점
- 표준이 존재하지 않음
- 제한적인 HTTP Method형태
- Header 작성이 쉽지 않다
REST 사용 이유
- 어플리케이션 분리 및 통합
- 다양한 클라이언트의 등장
- 다양한 브라우저 또는 모바일 디바이스에서도 통신할 수 있어야 함
- 멀티 플랫폼, 크로스 플랫폼에 대한 서비스 지원을 위해
REST 구성 요소
- 자원 ( Resource ) : URI
- 행위 ( Verb ) : HTTP Method
- 표현 ( Representation of Resource )
REST 특징
- 자원은 Server, 자원 요청은 Client
- 무상태 ( Stateless ) : 세션과 쿠키와 같은 Context 정보를 신경쓰지 않음
- 캐시처리 ( Cacheable ) : Last-Modified 태그 or E-Tag로 캐싱 구현 가능
- 계층화 ( Layerd System ) : 로드밸런싱, 공유캐시 등을 통해 확장성 및 보안성 향상 가능
- 인터페이스의 일관성 ( Uniform Interface ) : 특정 언어나 기술에 종속 되지 않음
REST API ?
REST 기반으로 서비스 API 를 구현한 것
마이크로 서비스 ( 하나의 큰 어플리케이션을 여러개의 작은 어플리케이션으로 쪼개 변경/조합이 가능하도록 만든 것 )
Open API ( 누구나 사용할 수 있도록 공개 된 API , 구글 맵 / 공공데이터 등 )
REST API 설계 규칙
- URI는 정보의 자원을 표현해야 한다. ( 동사보다는 명사 / 대문자보다는 소문자 등 )
- 자원에 대한 행위는 HTTP Method로 표현한다. ( URI에 HTTP Method 가 들어가면 안됨 )
- 슬래시 구분자 ( / ) 는 계층 관계를 나타내는데 사용한다.
- URI 마지막 문자에 슬래시 ( / ) 를 포함하지 않는다.
- 하이픈 ( - ) 은 URI 가독성을 높이는데 사용
- 밑줄 ( _ ) 은 URI 에 사용하지 않는다.
- URI 경로에는 소문자가 적합하다.
- 파일 확장자는 URI 에 포함시키지 않는다.
RESTful이란 ?
REST 아키텍처를 구현하는 웹 서비스를 나타내기 위해 사용되는 용어
REST API 를 제공하는 서비스를 "RESTful" 하다고 할 수 있다.
이해하기 쉽고 사용하기 쉬운 REST API 를 만드는 것
댓글