REST

REST는 Representational State Transfer라는 용어의 약자로서 2000년도에 로이 필딩 (Roy Fielding)의 박사학위 논문에서 최초로 소개되었다. 로이 필딩은 HTTP의 주요 저자 중 한 사람으로 그 당시 웹(HTTP) 설계의 우수성에 비해 제대로 사용되어지지 못하는 모습에 안타까워하며 웹의 장점을 최대한 활용할 수 있는 아키텍처로써 REST를 발표했다고 한다.

CRUD는 URL에 사용하면 안된다

GET, PUT, POST, DELETE는 CRUD와 1:1로 맵핑된다.

GET(retrieve) ,PUT(update), POST(create), DELETE(destroy)

실제로 장고에서 어떤 글을 생성할 때 URL 패턴을 post/create 와 같이 설계를 했다. 하지만 RESTful에서는 그렇게 설계하지 않는다. 기본적으로 form 체계에서는 POST와 GET밖에 사용하지 못하므로 나머지 요청에 대해서 어쩔 수 없이 동적인 URL을 쓸 수 밖에 없다. 이렇게 동사를 써서 URL을 디자인하는 방법은 옳지 않은 방법이다.

이 전에 썼던 옳지 않은 방법

POST /post/create
포스트 생성

GET /post/1/delete
포스트 삭제

같은 URL에 GET, PUT, POST, DELETE, PATCH 요청을 했을 때 전부 다른 결과가 생성이 된다. URL 자체에 어떤 Method를 주는 것이다. 이런식으로 설계를 한 다음에 Method만 다르게 주는 방식을 RESTful하다고 한다.

올바른 방법

http://www.siwon.com/sports/basketball
http://www.siwon.com/sports/basketball/teams
http://www.siwon.com/sports/basketball/teams/players
http://www.siwon.com/sports/basketball/teams/players/13/records

PATCH까지 포함하면 5개지만 GET, PUT, POST, DELETE만을 가지고 CRUD를 할 수 있다. 각 Method마다 올바른 방법이 있다. 아래 표를 보자.

http://www.siwon.com/sports/는 복수형 이므로 리스트를 가져오는 URI이다. GET 요청을하면 전체 스포츠 리스트를 가져오는 것이고, POST 요청을 하면 스포츠 리스트에 어떤 스포츠 종목을 하나 추가하는 것이다.
http://www.siwon.com/sports/basketball/는 여러개의 스포츠 중에서 한개만 가져온 것이다. GET 요청 특정 스포츠 종목에 대한 정보 하나만을 가져오는 것이고 PUT 요청은 어떤 정보를 업데이트, DELETE 요청은 이 종목을 지운다는 의미이다. 하지만 POST요청이 와서 생성해줄 건 없다. 왜냐하면, 이미 종목에 대한 정보가 생성된 상태이기 때문이다.

응답 상태 코드

출처 : http://remotty.github.io/blog/2014/01/28/lets-study-rest/

rfc2616을 살펴보면 많은 종류의 상태코드가 존재합니다. 상태코드를 적절히 잘 사용하면 클라이언트에게 많은 정보를 줄 수 있습니다.

성공

• 200 – 클라이언트의 요청을 정상적으로 수행하였을때 사용합니다. 응답 바디(body)엔 요청과 관련된 내용을 넣어줍니다. 그리고 200의 응답 바디에 오류 내용을 전송하는데 사용해서는 안된다고 합니다. 오류가 났을땐 - 40x 응답 코드를 권장합니다.
• 201 – 클라이언트가 어떤 리소스 생성을 요청하였고, 해당 리소스가 성공적으로 생성되었을때 사용합니다.
• 202 – 클라이언트의 요청이 비동기적으로 처리될때 사용합니다. 응답 바디에 처리되기까지의 시간 등의 정보를 넣어주면 좋다고 합니다.
• 204 – 클라이언트의 요청응 정상적으로 수행하였을때 사용합니다. 200과 다른점은 204는 응답 바디가 없을때 사용합니다. 예를들어 DELETE와 같은 요청시에 사용합니다. 클라이언트의 리소스 삭제요청이 성공했지만 부가적으로 응답 바디에 넣어서 알려줄만한 정보가 하나도 없을땐 204를 사용합니다.

실패

• 400 – 클라이언트의 요청이 부적절할때 사용합니다. 요청 실패시 가장 많이 사용될 상태코드로 예를들어 클라이언트에서 보낸 것들이 서버에서 유효성 검증(validation)을 통과하지 못하였을때 400으로 응답합니다. 응답 바디에 요청이 실패한 이유를 넣어줘야 합니다.
• 401 – 클라이언트가 인증되지 않은 상태에서 보호된 리소스를 요청했을때 사용하는 요청입니다. 예를들어 로그인(login)하지 않은 사용자가 로그인했을때에만 요청 가능한 리소스를 요청했을때 401을 응답합니다.
• 403 – 사용자 인증상태와 관계 없이 응답하고싶지 않은 리소스를 클라이언트가 요청했을때 사용합니다. 그러나 해당 응답코드 대신 400을 사용할 것을 권고합니다. 그 이유는 일단 403 응답이 왔다는것 자체는 해당 리소스가 존재한다는 뜻입니다. 응답하고싶지 않은 리소스는 존재 여부 조차 감추는게 보안상 좋기때문에 403을 응답해야할 요청에 대해선 그냥 400이나 404를 응답하는게 좋겠습니다.
• 404 – 클라이언트가 요청한 리소스가 존재 하지 않을때 사용하는 응답입니다.
• 405 – 클라이언트가 요청한 리소스에서는 사용 불가능한 Method를 이용했을때 사용하는 응답입니다. 예를들어 읽기전용 리소스에 DELETE Method를 사용했을때 405 응답을 하면 됩니다.

기타

• 301 – 클라이언트가 요청한 리소스에 대한 URI가 변경 되었을때 사용합니다. 응답시 Location header에 변경된 URI를 적어줘야 합니다.
• 500 – 서버에 뭔가 문제가 있을때 사용합니다.