REST API
•
HTTP의 장점을 최대한 활용할 수 있는 아키텍처
◦
이 REST의 기본원칙을 성실히 지킨 서비스 디자인을 "RESTful"이라고 표현
•
REST는 HTTP를 기반으로 클라이언트가 서버의 리소스에 접근하는 방식을 규정한 아키텍처
◦
REST API는 REST를 기반으로 서비스 API를 구현한 것
REST API의 구성
•
구성 요소
◦
자원(자원) - URI로 표현
◦
행위(자원에 대한 행위) - HTTP 요청 메서드
◦
표현(자원에 대한 행위의 구체적 내용) - 페이로드(PayLoad)
REST API 설계 원칙
•
기본적인 원칙 2가지
◦
URI는 리소스를 표현하는데 집중
◦
행위에 대한 정의는 HTTP 요청 메서드를 통해 하는 것
1.
URI는 리소스를 표현 --> 리소스의 이름은 동사보다 명사
2.
리소스에 대한 행위는 HTTP 요청 메서드로 표현 --> GET/POST/PUT/PATCH/DELETE를 사용하여 CRUD 구현
GET 요청
•
todos 리소스에서 모든 리소스 취득
POST 요청
•
todos 리소스에 새로운 todo를 요청하고 서버로 전송시 setRequestHeader를 사용하여 페이로드의 MIME 타입 지정 필요
PUT 요청
•
특정 리소스 전체를 교체할 때 사용. 마찬가지로 MIME 타입 지정 필요
PATCH 요청
•
특정 리소스의 일부를 수정할 때 사용. MIME 타입 지정 필요
DELETE 요청
•
todos 리소스에서 id를 사용하여 todo를 삭제
REST API 설계 예시
1.
URI는 동사보다는 명사를, 대문자보다는 소문자를 사용하여야 한다.
Bad Example http://khj93.com/Running/
Good Example http://khj93.com/run/
2.
마지막에 슬래시 (/)를 포함하지 않는다.
Bad Example http://khj93.com/test/
Good Example http://khj93.com/test
3.
언더바 대신 하이폰을 사용한다.
Bad Example http://khj93.com/test_blog
Good Example http://khj93.com/test-blog
4.
파일확장자는 URI에 포함하지 않는다.
Bad Example http://khj93.com/photo.jpg
Good Example http://khj93.com/photo
5.
행위를 포함하지 않는다.
Bad Example http://khj93.com/delete-post/1
Good Example http://khj93.com/post/1