REST API

참조 : https://meetup.toast.com/posts/92

• restful api라고도 하며, representational state transfer의 약자이다.
• 크게 자원(URI), 행위(Verb), 표현(Representations)로 구성되어 있다.
• Uniform Interface : URI를 통해 저장된 리소스에 대한 조작을 통일되고 안정된 인터페이스로 수행하는 아키텍처 스타일
• Stateless(무상태성) : 작업을 위한 상태 정보를 따로 저장하지 않는다. 들어오는 요청만 처리하면 된다.
• Cacheable(캐시 가능) : http를 사용하므로, http의 캐싱 기능을 적용할 수 있다. last modified 태그나 e-tag를 사용하면 구현할 수 있다.
• Self-descriptiveness(자체 표현 구조) : rest api의 메세지만 보고도 이를 쉽게 이해할 수 있다.
• Client - Server 구조 : rest 서버는 api 제공, 클라이언트는 사용자 인증이나 컨텍스트 등을 직접 관리하는 구조. 서로 개발해야 할 내용이 명확해지며 서로간 의존성도 줄어든다.
• 계층 구조 : 다중 계층으로 구성되며, 보안이나 로드 밸런싱 암호화 등의 계층을 추가해 구조상의 유연성을 확보할 수 있고, 프록시나 게이트웨이 같은 네트워크 기반의 중간매체를 사용할 수 있게 된다.
• rest api의 설계에서 기억할 건 딱 두 가지. URI는 정보의 자원을 표현해야 한다, 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE)로 표현해야 한다.
• URI는 정보의 자원을 표현하는 데 중점을 둬야 한다. 행위에 대한 표현이 들어가서는 안 되며, 그렇기 때문에 GET /members/2와 같은 형태가 되어야 한다. GET /members/delete/2는 잘못된 형태.
• 자원에 대한 행위를 HTTP Method로 표현해야 하기 때문에, 위의 잘못된 예시는 DELETE /members/2로 바꿔줄 수 있다.
• GET, POST, PUT, DELETE를 통해 CRUD를 구현할 수 있다. 이 경우 Create == POST, Read == GET, Update == PUT, Delete == DELETE와 같이 대응된다.