REST API

RESTful

 

RESTful 하다는 것은 REST API에 적합하게 설계 되었다는 의미입니다. REST API에 적합하다는 것은 REST API의 설계 원칙을 따랐다는 것이며, 이중에는 다음과 같은 원칙들이 있습니다. 

 

• stateless
  • HTTP는 기본적으로 connection에 대한 session을 맺지 않고 통신하는 프로토콜입니다. 
  • 즉, state를 유지하지 않고 통신해야 하기에 stateless 통신 프로토콜이라고 합니다. 
    • 이런 제약이 있기에 HTTP 통신에서는 cookie라는 별도의 data를 전송하여 state 정보를 주고 받기도 합니다. 
• resource oriented
  • 어떤 '동작'을 수행할 때, 그리고 어떤 '리소스'를 요청할 때 모두 특정 URL 기반으로 이들을 식별합니다. 
  • 동작과 리소스 등 다양한 기능을 URL을 통해서 식별하기에 resource oriented라고 합니다. 

여러가지 특징들이 있지만, 가장 큰 특징은 위 2가지 특징입니다. 

 

GET

data를 얻어오는데 사용하는 REST 통신 방식 입니다. 

 

URL

/test/get_image

 

위와 같은 URL이 있을 시 어떤 image data를 가져올지를 지정해야 하는데, 이는 request의 header에 값을 추가하는 방식으로 수행합니다. 

만약 1번 image를 얻어오고자 한다면, 

/test/get_image?image_num=1&image_size=full

image를 식별할 image_num과 가져올 image의 size type 두 가지를 인자로서 HTTP request header에 추가하는 형태로 요청이 전송됩니다. 

 

POST

POST는 data를 server에 전달하여 생성/갱신하는데 사용하는 통신 형태 입니다. 

GET의 경우 parameter들을 request의 header에 함께 싥어 보내게 됩니다. 즉, 모든것이 다 노출된다는 단점이 있습니다. POST 통신 방식의 경우 이러한 상세 데이터들을 header가 아닌 request body에 싥어 보내게 됩니다. 즉, 보안에 취약하지 않게 됩니다. 

 

/get/update_image_name

 

image_num=1&image_size=new_name

 

PUT

POST와 동일한 목적으로 사용됩니다만, 차이는 PUT은 idempotent하다는 점 입니다. 즉, PUT을 여러번 호출해도 언제나 같은 결과를 얻게 된다는 점이 POST와의 차이점 입니다. 반대로 POST의 경우 동일 resource에 대해 동일한 요청을 하게 되면  side effect가 발생할 수 있습니다. 

 

DELETE

특정 resource를 삭제 요청하는 method 입니다. 

 

	GET	POST
back button	don't care	data가 재 전송됨
bookmarked	bookmark 가능	불가능
cached	cache 가능	불가능
encoding type	application/x-www.form-urlencoded	application/x-www-form-urlencoded or multipart/form-data <-- used for binary data
history	parameter가 browser history에 남음	남지 않음
data length 제약	2048 characters	없음
data type 제약	ASCII only	제약 없음
security	less secure	litter bit safer than GET parameter가 browser history에 저장되지 않음
visibility	visible	not visible