Rest(Reoresentational State Transfer)
💡웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한 활용할 수 있는 아키텍쳐 스타일
즉 자원을 이름으로 구분하여 해당 자원의 상태를 주고 받는 소프트웨어 아키텍쳐
- HTTP URL을 통해 자원을 명시
- HTTP Method를 통해 해당 자원에 대한 CRUD Operation을 적용 하는 것
REST 의 구성요소
1. 자원(resource)
- 모든 자원에는 고유한 ID가 서버에 존재
- 자원을 구별하는 ID는 HTTP URI
2. 자원에 대한 행위(Verb)
- HTTP Method(GET,POST,PUT,DELETE)를 사용
3. 자원에 대한 행위의 내용(Representations)
- HTTP Message Pay Load
- Client가 자원의 상태에 대한 조작을 요청하면 Server는 이에 적절한 응답을 보냄
- 현재는 JSON으로 주고 받는 것이 대부분
REST 의 특징
1. Server-Client( 서버 클라이언트 구조)
2. Stateless(무상태)
: 서버에서 어떤 작업을 하기위해 상태 정보를 기억할 필요가 없다 들어온 요청에 대해 처리만 해주면 됨
3. Cacheable(캐시 처리 가능)
4. Layered System(계층화)
: 클라이언트와 서버가 분리 되어있어 프록시 서버,암호화 계층 등 중간 매체를 사용할 수 있어 자유도가 높음
5. Uniform Interface(인터페이스 일관성)
: 특정 언어나 기술에 종속되지 않음
REST의 장단점
| REST의 장점 |
REST 의 단점 |
| HTTP 표준 프로토콜을 따르는 모든 플랫폼에서 사용이 가능 |
HTTP Method가 제한적 |
| HTTP 프로토콜의 인프라를 그대로사용하여 REST API 사용을 위한 별도의 인프라를 구출할 필요가 없음 |
표준이 자체가 존재하지 않아 정의가 필요 |
REST API 란
💡HTTP와 URI 기반으로 자원에 접근할 수 있도록 제공하는 애플리케이션 개발 인터페이스
즉, REST의 원리를 따르는 API
REST API 설계 규칙
1. URI는 동사보다는 명사를 대문자보다는 소문자를 사용
2. 마지막에 슬래쉬를 포함하지 않는다
3. 언더바 대신 하이픈 사용
4. 확장자는 URI에 포함하지 않음
5. 행위(즉 메스드)는 포함하지 않는다
6. 슬래시 구분자는 계층 관계를 나타내는데 사용
RESTful API 개발 원칙
1. 자원을 식별할 수 있어야한다
: URL만으로 어떤 자원을 제어하려고 하는지 알수 있어야한다
2. 행위가 명시적이여야한다
: REST 아키텍쳐에 부합해야한다
ex) GET을 이용해서 UPDATE와 DELETE를 구현하면 REST를 따른다고 할 수 없음
3. 자기 서술적이어야한다
: 데이터에 대한 메타 정보만 가지고도 어떤 종류의 데이터인지 데이터를 위해서 어떤 어플리케이션을 실행해야하는지 알 수 있어야 한다