REST(Representational State Transfer)

API(Application Programming Interface)

< REST API >

[what is REST]

- 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식

- Roy Fielding이 2000년 박사 학위 논문에 REST를 정의

- REST: 네트워크 아키텍처 원리의 모음

->  네트워크 아키텍처 원리 = 자원 정의 / 자원에 대한 주소 지정 방법 전반

->  간단히 말하면, 웹 상의 자료를 HTTP 위에서 별도의 전송 계층 없이 전송하기 위한 간단한 INTERFACE

--> Fielding 의 REST 아키텍처 형식 따르면

1)  HTTP나 WWW 이외 큰 소프트웨어 시스템 설계 가능

2) Remort Procedure call대신 간단 XML , HTTP INTERFACE 이용한 설계 가능

--> Fielding 의 REST 원리 따르는 시스템 의 지칭 : RESTful

[REST architecture 6가지 제한 조건]

: 다음 제한 조건 준수하면 해당 컴포넌트 자유롭게 구현 가능

1) 인터페이스 일관성 ( Uniform Interface)

2) 무상태 (Stateless)

3) 캐시 처리 가능 (Cacheable)

4) 클라이언트/서버 구조 (Client-Server)

5) 계층화 (Layered System)

6) Code on Demand (Optional)

[REST 주 목표] 

1) 구성 요소 상호작용의 규모 확장성

2) 인터페이스 범용성

3) 구성 요소의 독립적 배포

4) 중간적 구성요소 이용한 응답 지연 감소, 보안 강화, 레거시 시스템 인캡슐레이션

[REST API DESIGN GUIDE]

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 설계의 중심 규칙

[HTTP 응답 상태 코드 의미]

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