1. 태생의 기원

REST 개요

REST 는 HTTP 메서드와 URI 사용 등의 웹 표준을 준수하는 아키텍처 스타일로 다음과 같은 기본 철학을 갖고 있다.

1. 모든 리소스를 URI로 구분할 수 있다.
2. 모든 리소스는 복수의 형태로 나타낼 수 있다.
3. 모든 리소스는 HTTP 표준 메서드를 이용하여 접근/수정/삭제 할 수 있다.
4. 서버에는 어떤 정보도 갖고 있지 않다.

1) REST와 무상태성

REST는 무상태성을 기본으로 한다. 클라이언트에서 서버로 전달되는 요청에 가능한 모든 정보가 포함되어야 하며, 덕분에 요청에 대한 가시성, 가독성, 확장성이 향상된다.

• 가시성: 시스템이 요청을 모니터링하고 있다가 상세한 정보를 알고 싶을 때 요청 객체를 다시 파헤쳐보지 않아도 되므로 가시성이 좋아진다.

• 가독성: 서버 실행 중 부분적인 장애가 발생하여도 체크포인트나 실행을 재개할 지점따위는 생각하지 않아도된다.

• 확장성: 서버측에 상태를 따로 보관하지 않기 때문에 서버를 증설한 만큼 비례하여 요청처리한도가 증가한다.

안전과 멱등성

1) 안전한 메서드

안전한 메서드란 서버 측의 상태 정보를 변경하지 않는 메서드를 의미한다 (GET v1/books/orders/1111).
GET, HEAD 와 같은 안전한 메서드는 캐시가 가능하다.

2) 멱등한 메서드

멱등한 메서드란 몇 번을 호출하더라도 동일한 결과를 반환하는 메서드를 의미한다.

• GET 메서드는 여러번 호출해도 나간 리소스는 동일한 응답을 하므로, PUT 메서드는 동일한 리소스를 업데이트하고 그 이후에도 결과가 달라지지 않으므로 멱등하다.

• POST는 복수 호출 시 각기 다른 결과가 리턴되거나 새로운 리소스가 계혹 만들어질 수 있으므로 멱등하지 않다.

• DELETE는 처음에 리소스가 삭제되면 더 이상 존재하지 않고 여러번 호출해도 결과가 달라지지 않으므로 멱등하다.

RESTful 서비스의 설계 원칙

1) 리소스 URL 결정

모든 RESTful 리소스는 URI 로 식별된다. REST가 확장성이 좋다고 하는 것은 이때문이다. 아래의 표는 시스템 리소스를 URI로 나타낸 예시다.

표의 URI는 모두 클라이언트 입장에서 해석하기 매우 좋은, 가독성이 우수한 패턴을 가지고 있다. 리소스는 JSON, XML, HTML, 일반 텍스트 등의 형태로 표현할 수 있고 GET, PUT, POST, DELETE 같은 메서드로 처리할 수 있다.

2) 리소스 메서드 결정

HTTP 메서드는 단일 인터페이스 제약 조건을 구성하는 중요한 요소이며, 동사 기반의 액션과 명사 기반의 리소스간 연관관계를 정의한다.

3) HTTP와 메서드 REST

HTTP 메서드는 서버가 URL 의 일부로 던져진 데이터를 갖고 어떤 일을 해야할지 알려준다.

GET ]

GET은 가장 간단한 HTTP 메서드로, 리소스에 접근할 수 있게 해준다. 브라우저에서 주소 입력 후 클릭하면 URL 주소에 해당하는 서버로 GET 요청을 한다.

GET은 안전하고 멱등한 메서드다. GET 요청을 캐시에 보관되며, 요청 문자열 끝에 쿼리 파라미터를 덧붙일 수 있다.

POST ]

POST는 리소스를 생성하는 메서드로, POST 요청은 안전하지도, 멱등하지도 않다. POST 요청을 여러번 하면 여러개의 리소스가 만들어질 수 있고, 캐시 엔트리가 있다면 이를 전부 무효화시킨다.

POST 요청에는 파라미터를 붙이지 않는것이 좋다.

PUT ]

PUT은 리소스를 변경하기 위해 사용되며, 멱등하지만 안전하지 않은 메서드다. PUT 메서드는 여러 차례 호출해도 동일한 리소스를 변경하므로 결과는 동일하다. PUT 요청 역시 캐시 엔트리가 존재할 경우 이를 무효화 시킨다.

DELETE ]

DELETE 는 메소르를 삭제하는 메서드며, 멱등하지만 안전하지는 않다. RFC2616 문서에 따르면 복수의 DELETE 요청을 단일 DELETE 요청과 결과가 동일하므로 멱등하다.

리소스가 한 번 삭제된 후에는 또다시 DELETE 요청을 여러 번 한다 해도 결과는 같기 때문이다.

HEAD ]

HEAD는 GET과 유사한데 차이점이 있다면 콘텐츠가 가는 HTTP 헤더만 반환한다는 것이다. HEAD는 안전하고 멱등한 메서드이다.

PUT과 POST 의 차이 ]

POST 메서드는 요청을 처리할 엔티티를 Ruquest-URI 로 지정하지만, PUT 메서드는 Request-URI 자체에 이미 엔티티가 포함되어 있다.

• POST /v1/coffee/orders : 주문 데이터를 생성한 뒤 생성된 리소스를 가리키는 식별자를 반환한다.

• PUT /v1/coffee/orders/123 : 주문번호 123의 리소스가 존재하면 업데이트하고, 존재하지 않을 경우 주문 번호가 123인 데이터를 생성한뒤 식별자로 사용한다.

4) 리소스 표현형 결정

RESTful 리소스는 추상적인 엔티티이므로, 어떤 표현형으로 직렬화하여 클라이언트에 전달해야 한다. 일반적으로 많이 쓰는 리소스 표현형은 XML, JSON, HTML, 일반 텍스트 다.

서버 리소스는 클라이언트 측에서 처리 가능한 표현형으로 전달하여, 클라이언트가 어떤 언어와 미디어 타입을 원하는지 먼저 서버에게 알려줄 수 있다. 이를 콘텐츠 협상이라고 한다.

리소스 설계에 대한 베스트 프랙티스

1. API 개발자는 명사와 HTTP 메서드를 사용하여 리소스를 구별하고 이해하기 쉬운 형태로 설계한다.

2. 서브 리소스는 URI 를 연관지어 구별되도록 한다. (Ex. /user/1234/books/8888/authors)

3. 그밖의 조건은 파라미터로 정한다. (Ex. /user/1234/books?reviews_counts=10)

4. 응답 레코드의 일부만 필요한 경우 쿼리 파라미터에 명시한다. 예컨대 원하는 정보가 유저의 이름과 나이뿐이라면 클라이언트 측에서는 ?필드 쿼리파라미터를 붙여 서버가 응답해야 할 정보가 무엇인지 밝힌다.
   (Ex. /user/1234?fields=name,age)

5. 클라이언트가 원하는 출력 포맷을 지정하지 않을 수도 있기 때문에 기본 포맷을 정한다.

6. 속성은 카멜 또는 언더파 표기법으로 명명한다.

7. 개수를 세는 표준 API를 지원하는 것이 좋다. 클라이언트 입장에서는 사전에 몇 건의 응답 객체가 리턴될 지 알 길이 없기 때문이다. 또한 이렇게 하면 클라이언트 측에서 페이지네이션 쿼리를 하는데 도움이 된다.

8. 깔끔하게 출력할 수 있는 옵션을 제공한다.

9. 서버 응답에는 가능한 상세한 내용을 담아서 클라이언트와 서버가 다시 얘기를 나눌 필요가 없도록 한다.