Roy Fielding 의 2000년 논문에 의해 소개. 
웹의 장점을 최대한 활용할 수 있는 네트워크 기반의 아키텍쳐, Representational state transfer (REST)  

3가지요소 (리소스메소드메시지)로 구성

HTTP POST, http://test/user/ 

"id":"developyo", 
"blog":"https://developyo.tistory.com/" 

위 요청은 POST 메소드(create), 생성 대상이 되는 리소스인 http://test/user/ 
생성하고자 하는 사용자 내용은 JSON 을 사용 

[HTTP 메소드]

POST,GET,PUT,DELETE 만 사용 

POST : create, Idempotent X 
GET : select, Idempotent O 
PUT : update, Idempotent O 
DELETE : delete, Idempotent O 

POST, GET, PUT, DELETE 는 CRUD 역할 
Idempotent 한 메소드(GET, PUT, DELETE)는 수행 실패시 한 번 더 호출하면 되지만 Idempotent 하지 않은 메소드(POST(create))는 실패시 트랜잭션 처리에 주의해야한다. 


※ Idempotent 는 여러번 호출되도 같은 실행결과가 나오는 것을 의미한다. 
예를 들어 a++는 호출시마다 값이 증가하므로 Idempotent 하지 않으며, a=1 은 호출시 값이 같으므로 Idempotent 하다. 

[REST의 리소스]

REST는 리소스 지향 아키텍쳐 스타일 답게 모든 것을 리소스(명사)로 표현, 각 세부 리소스에는 id 를 붙임 
즉 사용자라는 리소스 타입을 http://test/user 라고 정의했다면 
developyo 란 id를 갖는 리소스는 http://test/user/developyo 와 같이 표현 

POST/생성 의 예 :

HTTP POST, http://test/user/ 

"id":"developyo", 
"blog":"https://developyo.tistory.com/" 

GET/조회 의 예 :

HTTP GET, http://test/user/developyo 

PUT/수정 의 예 :

HTTP PUT, http://test/user/developyo 

"id":"developyo", 
"blog":"https://developyo2.tistory.com/" 

DELETE/삭제 의 예 :

HTTP DELETE, http://test/user/developyo 

 

[REST의 특징]

1. 유니폼 인터페이스(Uniform interface) : 
특정 언어나 기술에 종속받지 않으며 HTTP와 JSON(혹은 XML)을 사용할 수 있는 모든 플랫폼에서 사용이 가능한 느슨한 결합 형태의 구조 
2. 무상태성(stateless) : 클라이언트 상태를 서버쪽에 유지하지 않는다는 의미 (참고)
3. 캐싱 가능 
4. 자체 표현 구조 : 직관적인 이해가 가능 
5. 클라이언트 서버 구조 

[REST 안티 패턴]

1. GET/POST 터널링 : http://test/user?id=developyo&method=update (GET 터널링의 예)
2. 자체 표현 구조가 아닌 경우 (위 1번과 같은 경우) 
3. response code 사용하지 않음 :
response code 는 항상 200(성공) 으로 응답하며, 실제 성공/실패 리턴코드를 body 에 담아 따로 리턴하는 경우

 

 

참고 : https://bcho.tistory.com/953

참고 : https://blog.npcode.com/2017/04/03/rest%EC%9D%98-representation%EC%9D%B4%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80/

 

반응형

+ Recent posts