REST(Representational State Transfer)
API(Application Programming Interface)
- 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식
- Roy Fielding이 2000년 박사 학위 논문에 REST를 정의
- REST: 네트워크 아키텍처 원리의 모음
-> 네트워크 아키텍처 원리 = 자원 정의 / 자원에 대한 주소 지정 방법 전반
-> 간단히 말하면, 웹 상의 자료를 HTTP 위에서 별도의 전송 계층 없이 전송하기 위한 간단한 INTERFACE
--> Fielding 의 REST 아키텍처 형식 따르면
1) HTTP나 WWW 이외 큰 소프트웨어 시스템 설계 가능
2) Remort Procedure call대신 간단 XML , HTTP INTERFACE 이용한 설계 가능
--> Fielding 의 REST 원리 따르는 시스템 의 지칭 : RESTful
: 다음 제한 조건 준수하면 해당 컴포넌트 자유롭게 구현 가능
1) 인터페이스 일관성 ( Uniform Interface)
2) 무상태 (Stateless)
3) 캐시 처리 가능 (Cacheable)
4) 클라이언트/서버 구조 (Client-Server)
5) 계층화 (Layered System)
6) Code on Demand (Optional)
1) 구성 요소 상호작용의 규모 확장성
2) 인터페이스 범용성
3) 구성 요소의 독립적 배포
4) 중간적 구성요소 이용한 응답 지연 감소, 보안 강화, 레거시 시스템 인캡슐레이션
1) URL은 정보의 자원 표현해야 함
GET /members/delete/1- 위 표현은 잘못된 URI (자원 표현에 집중해야 함)
DELETE /members/1 (o) GET /members/show/1 (x) GET /members/insert/2 (x) GET /members/1 (o) GET /members/2 (o)2) 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE)로 표현
- POST / GET / PUT / DELETE Method로 CRUD가능
- POST : URL요청후 리소스 생성
- GET : 해당 리소스 조회 -> 해당 DOCUMENT대한 자세한 정보 가져옴
- PUT : 해당 리소스 수
- DELETE : 리소스 삭제
즉, URI = 자원 표현에 집중 HTTP METHOD = 행위에 대한 정의
-> REST한 API 설계의 중심 규칙
200 - 클라이언트 요청 정상적으로 수행함
201 - 클라이언트가 어떤 리소스 생성 요청, 그리고 해당 리소스가 성공적으로 생성됨(POST통한 리소스 생성 작업 시)
301 - 클라이언트가 요청한 리소스에 대한 URI 변경 되었을 시 사용
400 - 클라이언트 요청이 부적절한 경우 사용
401 - 인증되지 않은 상태에서 클라이언트가 보호된 리소스 요청시 사용
403 - 유저 인증상태와 관계 없이 응답하고 싶지 않은 리소스를 클라이언트가 요청시 사용 (리소스는 존재)
404 - 클라이언트가 요청한 리소스가 존재하지 않음
405 - 클라이언트가 요청한 리소스에 사용 불가능한 Method 이용했을 경우 사용
500 - 서버에 문제 있을 시 사용
<REFERENCE>
1. https://ko.wikipedia.org/wiki/REST
2. http://meetup.toast.com/posts/92