1.Rest API 모델의 이해
2.Rest API의 개념
REST & API 정의
리소스를 다룰때 인터페이스에서 정의한 방식으로만 다룰 수 있다는 의미이다.
사용자와 클라이언트가 얻으려 하는 리소스 사이의 조정자라고 할 수 있다.
클라이언트의 시스템과 상호작용하여 정보를 검색하거나 기능을 수행하고자 할 때, API를 통해 요청사항을 전달 함으로써 시스템이 요청을 이해하고 응답할 수 있다.
REST API의 탄생 배경
HTTP의 주요 저자중 한명인 로이 필딩(Roy Fielding)은 많은 사람들이 웹 설계의 우수성을 이해하지 못한채 사용하고 있던게 아쉬워 웹의 장점을 최대한 활용할 수 있는 아키텍처로 REST라는 개념을 제안하였다.
REST는 프로토콜이나 표준이 아닌 아키텍처 원칙!
REST의 특징
- Uniform Interface
:URI로 지정한 리소스를 인터페이스를 통해서만 조작하는 아키텍처 스타일을 사용한다 - Stateless
: state(상태)를 저장하지 않는다. 상태를 저장하지 않으므로 서버에게 주는 부담을 줄일 수 있다. - Cacheable
: HTTP라는 웹 표준을 쓰기 때문에 웹에서 지원하는 캐싱 기능을 사용할 수 있다. - Self-descriptiveness(자체표현구조)
: 표현(REST API 메시지)만 보고도 어떤 요청인지 이해할 수 있다. - Client-Server 구조
: 서버와 클라이언트의 역할이 명확하다. 따라서 서로간에 의존성이 줄어든다. - 계층형 구조
: 다층으로 구성할 수 있기 때문에 보안, 암호화 계층을 별도로 추가할 수 있고, proxy, gateway 같은 네트워크 기반의 중간매체도 이용할 수 있다.
다음 규칙들을 따르는 API를 RESTful API라고 한다.
REST의 구성
1.자원(Resource): URI
2.행위(Verb): HTTP Method
3,표현(Representation): Payload
REST API 설계하기
아래의 링크를 참고
https://luckyguystory.tistory.com/96
: 리소스 '자체'와 리소스에 대한 '행위'를 분리하여 설계해야 한다
URI는 정보의 리소스(자원)를 표현하는데 사용해야 한다
GET /Users/1 (O)
-> 리소스이름은 주로 명사를 사용한다
GET /Users/update/1 (X)
-> URI는 리소스 자체 위주로 표기해야한다. 리소스에 대한 행위 를 표현하면 안된다!
리소스에 대한 행위는 HTTP Method를 사용한다
(다음 4개의 메소드를 통해 데이터 CRUD를 할 수 있다)
- POST: 데이터를 새로 추가할 때 사용
- GET: 데이터를 받을 때만 사용
- PUT: 기존의 데이터를 수정할 때 사용
- DELETE: 기존의 데이터를 삭제할 때 사용
HTTP 상태 코드
추가 개념
-
URI (Uniform Resource Identifier) : 네트워크 상에 존재하는 자원을 구분하는 식별자(ID)로서 의미가 강하다.
-
URL (Uniform Resource Locator) : 네트워크 상에 존재하는 자원의 위치를 말합니다. 즉 자원의 어디에 있는지 나타내는 Where의 개념
-
URN (Uniform Resource Name) : 자원의 이름을 나타내는 말이다. 즉 자원이 무엇인지를 말하는 What의 개념으로 이해할 수 있다. URN은 서로 중복되지 않는 유일한 값이어야 한다.
