Rest
- 탄생 배경
- REST API의 등장은 2000년도에 HTTP의 주요 저자 중 한 사람인 로이 필딩이 그 당시 웹 설계의 우수성에 비해 제대로 사용되어지지 못하는 모습을 보고
- 웹의 장점을 최대한 활용할 수 있는 Architecture로써 REST를 발표 했습니다
- 개념
- Representational State Transfer의 약자
- HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고, HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD 명령을 적용하는 것을 의미
- 구성
- 자원 (Resource) : URI
- 자원을 구별하는 ID는 ‘/groups/:group_id’와 같은 HTTP URI 입니다.
- 행위 (Method) : HTTP Method
- HTTP Method (post, get, put, patch, delete) 이용
- 표현 : Representation of Resource
- JSON 혹은 XML를 통해 데이터를 주고 받는 것이 일반적입니다.
- 특징
- Uniform Interface : URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일을 의미
- Stateless (무상태성) : 작업을 위한 상태정보를 따로 저장하고 관리하지 않음
- Cacheable (캐시 가능) : HTTP라는 기존 웹표준을 그대로 사용하기 때문에 웹에서 사용하는 기존 인프라를 그대로 활용 가능 //HTTP가 가진 캐싱 기능 적용 가능
- Self-descriptiveness (자체 표현 구조) : REST API 메시지만 보고도 이를 쉽게 이해 할 수 있는 자체 표현 구조로 되어 있음
- Client - Server 구조 : REST 서버는 API 제공, 클라이언트는 사용자 인증이나 컨텍스트(세션, 로그인 정보)등을 직접 관리하는 구조로 각각의 역할이 확실히 구분되어 있음
- 계층형 구조 : REST 서버는 다중 계층으로 구성될 수 있음 (ex, 보안, 로드 밸런싱, 암호화 계층을 추가해 구조상의 유연성을 둘 수 있고 PROXY, 게이트웨이 사용 가능)
Rest API
- 등장 배경
- 최근의 서버 프로그램은 여러 웹 브라우저는 물론이며, 아이폰, 안드로이드 애플리케이션과의 통신에 대응할 수 있어야 합니다.
- 따라서 플랫폼에 맞추어 새로운 서버를 만드는 수고를 들이지 않기 위해 범용적으로 사용성을 보장하는 서버 디자인이 필요하게 되었습니다.
- 개념
- URI를 통해 자원(resource)을 명시하고 HTTP 메서드로 자원(resource)을 제어할 수 있게 CRUD 명령을 제공하는 애플리케이션 개발 인터페이스
- 개발자는 HTTP 메소드와 URI 만으로 홈페이지에 자료를 CRUD를 할 수 있습니다.
- 설계 규칙
- URI는 정보의 자원을 표현해야 한다
- resource는 동사보다는 명사를, 대문자보다는 소문자를 사용
- resource의 컬렉션 이름으로는 복수 명사를 사용해야 한다.
(ex, GET /users)
- 자원에 대한 행위는 함수 대신 HTTP 메서드 (GET, PUT, PATCH, POST, DELETE)로 표현한다
- 슬래시 (/ )는 계층 관계를 나타내는데 사용
- URI 마지막 문자로 슬래시(/ )를 포함하지 않는다.
- 긴 URI경로의 경우 언더바 대신 하이픈(-)을 사용하여 가독성을 높인다.
- 밑줄(_)은 URI에 사용하지 않는다.
- URI 경로에는 소문자가 적합
- 파일확장자는 URI에 포함하지 않는다.
- 리소스간의 연관관계는 다음과 같이 표현
- /리소스명/리소스 ID/관련된 다른 리소스명
- ex) GET /users/{userid}/likes/devices : 사용자가 좋아하는 디바이스 목록을 리턴
- 응답 코드
- 200번대 : 클라이언트의 요청을 수락하고 서버에서 성공적으로 처리됩니다.
- 300번대 : URL 리디렉션과 관련됨
- 400번대 : 클라이언트 측 오류
- 500번대 : 서버 측 오류