REST 이해하기

스프링으로 RESTful 서비스를 만들기 전에 RESTful에대한 준비를 합니다.

스프링 사이트에 있는 REST관련 문서와 가이드를 번역해서 차례로 공유합니다.

첫번째 문서는 Understanding REST입니다.

원본 문서는 https://spring.io/understanding/REST 에서 보실 수 있습니다.

라이센스는 원본 문서와 동일한 CC BY-ND 3.0 입니다.

REST 이해하기

REST(Representational State Transfer)는 로리 필딩(Roy Fielding)이 2000년도에 작성한 박사학위 논문에서 소개되었습니다. REST는 분산 시스템을 설계하기 위한 아키텍처의 한 형태입니다. 표준으로 정해진 것은 아니지만 몇가지 요건을 제시하고 있습니다. 상태를 저장하기 않을 것, 클라이언트/서버 관계일 것, 동일한 인터페이스를 사용할 것 등입니다. 필수 요건은 아니지만 대부분의 REST는 HTTP를 사용해서 구현이 되고 있습니다.

Designed by Freepik

REST 원칙

• 리소스(Resources) : 쉽게 이해할 수 있는 디렉토리 구조 URI로 표현됩니다.
• 리소스 표현(Representational) : 데이터 오브젝트와 속성을 표현하기 위해서 JSON이나 XML을 전송합니다.
• 메시지(Message) : HTTP 메쏘드를 사용합니다. (GET, POST, PUT, DELETE 등)
• 무상태(Stateless) : 서버는 클라이언트로부터 들어오는 요청에 대해서 상태를 저장하지 않습니다. 상태를 저장하면 확장성을 제한하게 됩니다. 세션의 상태는 클라이언트에서 저장을 합니다.

HTTP 메쏘드

CRUD(create, retrieve, update, delete)을 구현하기 위해서 HTTP 메쏘드를 사용합니다.

GET

정보를 얻을 때 사용합니다. GET 요청은 항상 일관성있는 결과를 전달해야합니다. 동일할 파라미터로 동일한 요청을 반복하면 항상 같은 결과를 받을 수 있어야합니다. 동일한 요청을 반복해서 하는 것으로 인해 서버에서 어떤 조치를 취할 수는 있겠지만 클라이언트가 그런 것을 고려하게 해서는 안됩니다. 결과적으로 GET 요청은 시스템에 중대한 영향을 끼칠 수 있는 것이 아니어야합니다. 리소스 일부 혹은 특정 리소스를 지정해서 요청할 수 있습니다.

ID가 1인 어드레스를 요청하는 예입니다.

GET /addresses/1

POST

URI로 지정된 리소스에 무언가를 하도록 요청합니다. 이때 함께 전달된 정보를 사용합니다. 보통은 POST는 새로운 리소스를 생성하는데 사용을 합니다. 하지만 기존에 존재하는 리소를 업데이트 하는데 사용될 수도 있습니다.

새 어드레스를 생성하는 예입니다.

POST /addresses

PUT

URI로 지정된 리소스에 정보를 저장합니다. PUT으로 이미 존재하던 정보를 변경할 수도 있고, 없던 것을 생성할 수도 있습니다. PUT 요청은 동일한 파라미터로 몇번을 반복해도 동일한 효과가 나타납니다.(idempotent) 이 특성이 PUT과 POST의 큰 차이점입니다.

ID가 1인 어드레스를 수정하는 예입니다.

PUT /addresses/1

Note : PUT은 기존 정보를 대체합니다. 만일 리소스의 속성중에서 일부 속성 데이터만 제공이 된다면 나머지 속성은 공백으로 처리되거나 null로 채워집니다.

PATCH

URI로 지정된 리소스에서 지정된 속성만 업데이트를 합니다. PUT 요청은 동일한 파라미터로 몇번을 반복해도 동일한 효과가 나타납니다.(idempotent) 이 특성이 PATCH과 POST의 큰 차이점입니다.

PATCH /addresses/1

DELETE

지정된 리소스 삭제를 요청합니다. 이 요청에따라 리소스가 바로 삭제될 필요는 없습니다. 어싱크하게 삭제가 될 수도 있고 일정 시간이 흐른뒤에 삭제될 수도 있습니다.

ID가 1일 어드레스를 삭제하는 예입니다.

DELETE /addresses/1

HTTP 상태 코드

상태 코드를 통해서 HTTP요처의 결과를 알 수 있습니다.

• 1XX : 정보
• 2XX : 성공
• 3XX : 리다이렉트
• 4XX : 클라이언트 에러
• 5XX : 서버 에러

미디어 타입

HTTP 헤더중에서 Accept와 Content-Type로 HTTP로 받기를 기대하거나 보내는 데이터의 타입을 정할 수 있습니다. 클라이언트가  JSON 응답을 원하는 경우 Accept를 application/json으로 설정해서 요청을 보낼 수 있습니다. 서버는 Content-Type를 application/xml 로 설정해서 보냄으로 클라이언트에게 데이터가 XML 타입이라고 알려줄 수 있습니다.