"그런 REST API 로 괜찮은가" 라는 꽤 유명한 영상을 보고
rest api 아키텍처에 그렇게 많은 규칙이 있는 줄 몰랐다.
단순히 get,post 등의 메소드설정, 정보전달, 약간의 네이밍 주의(?)
내가 그동안 고려했던 것은 이게 다였다.
Restful api = rest 스러운 api
그럼 rest 가 뭔데?
re - representational(상태)
s - state(표현)
t - transfer(주고받음)
"사람이 인지하기 쉽게 상태를 표현" 하는것으로 풀어 해석할수 있다.
http /uri + /주소 + /자원
c - Post
r - Get
u - Put
d - Delete
HTTP URI를 통해 자원을 명시하고, HTTP Method(Post,Get,Put,Delete)를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것
이라고 볼 수 있다.
규칙들
1. 네이밍 관련
- / 구분자는 계층관계를 나타내야 한다
- 도큐먼트 이름으로 단수명사
- 컬렉션 이름으로 복수명사
- 컨트롤러 이름으로는 동사나 동사구 사용
2.crud 관련
- put 메서드는 리소스를 삽입하거나, 갱신
- post 메서드는 새로운 리소스 생성
- delete 메서드는 그 부모로 부터 리소스 삭제
-> post,get,put,delete를 용도에 맞게 쓰자
3.응답 헤더값 관련
http api 와 restful api 비교
- 반환된 데이터에 대한 대체 위치 가리키는 content-location 헤더 추가
- 연결된 리소스의 링크정보 같이 내보내기
그럼 이러한 것들을 지켜 설계했을때 REST의 장점은 무엇일까?
-
HTTP 프로토콜의 인프라를 그대로 사용하므로 REST API 사용을 위한 별도의 인프라를 구출할 필요가 없다.
-
HTTP 프로토콜의 표준을 최대한 활용하여 여러 추가적인 장점을 함께 가져갈 수 있게 해준다.
-
HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다.
-
Hypermedia API의 기본을 충실히 지키면서 범용성을 보장한다.
-
REST API 메시지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악할 수 있다.
-
여러가지 서비스 디자인에서 생길 수 있는 문제를 최소화한다.
-
서버와 클라이언트의 역할을 명확하게 분리한다.
단점은??
- 사용할 수 있는 메소드가 4가지 밖에 없다.
- HTTP Method 형태가 제한적이다.
- 브라우저를 통해 테스트할 일이 많은 서비스라면 쉽게 고칠 수 있는 URL보다 Header 값이 왠지 더 어렵게 느껴진다.
- 구형 브라우저가 아직 제대로 지원해주지 못하는 부분이 존재한다.
- PUT, DELETE를 사용하지 못하는 점
- pushState를 지원하지 않는 점
REST 가 필요한 이유
- 애플리케이션 분리 및 통합’
- ‘다양한 클라이언트의 등장’
- 최근의 서버 프로그램은 다양한 브라우저와 안드로이폰, 아이폰과 같은 모바일 디바이스에서도 통신을 할 수 있어야 한다.
- 이러한 멀티 플랫폼에 대한 지원을 위해 서비스 자원에 대한 아키텍처를 세우고 이용하는 방법을 모색해야 한다.
