REST란?
- REpresentational State Transfer, Roy Fielding
- REST는 하나의 아키텍처로 볼 수 있다. 좀 더 정확한 표현으로 말하자면, REST 는
Resource Oriented Architecture이다. API 설계의 중심에 자원(Resource)이 있고 HTTP Method 를 통해 자원을 처리하도록 설계하는 것이다.
REST API 디자인 가이드
1) URI는 정보의 자원을 표현해야 한다. → 리소스명은 동사보다는 명사를 사용
2) 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE 등)로 표현
3) POST, GET, PUT, DELETE 이 4가지의 Method를 가지고 CRUD를 할 수 있습니다.
- POST – Create: 해당 URI를 요청하면 리소스를 생성합니다.
- GET – Read : 해당 리소스를 조회합니다. 리소스를 조회하고 해당 도큐먼트에 대한 자세한 정보를 가져온다.
- PUT – Update : 해당 리소스를 수정합니다.
- DELETE – Delete : 리소스를 삭제합니다.
4) URI 마지막 문자로 슬래시(/)를 포함하지 않는다.
REST 6 가지 원칙
- Client-Server – 클라이언트-서버 스타일은 사용자 인터페이스에 대한 관심(concern)을 데이터 저장에 대한 관심으로부터 분리함으로써 클라이언트의 이식성과 서버의 규모확장성을 개선한다.
- Stateless – 클라이언트와 서버의 통신에는 상태가 없어야한다. 모든 요청은 필요한 모든 정보를 담고 있어야한다. 요청 하나만 봐도 바로 뭔지 알 수 있으므로 가시성이 개선되고, task 실패시 복원이 쉬우므로 신뢰성이 개선되며, 상태를 저장할 필요가 없으므로 규모확장성이 개선된다.
- Cache – 캐시가 가능해야한다. 즉 모든 서버 응답은 캐시 가능한지 그렇지 아닌지 알 수 있어야한다. 호율, 규모확장성, 사용자 입장에서의 성능이 개선된다.
- Uniform Interface – 구성요소(클라이언트, 서버 등) 사이의 인터페이스는 균일(uniform)해야한다. 인터페이스를 일반화함으로써, 전체 시스템 아키텍처가 단순해지고, 상호작용의 가시성이 개선되며, 구현과 서비스가 분리되므로 독립적인 진화가 가능해진다.
- Layered System – hierarchy로 구성이 가능해야하며, 각 레이어에 속한 구성요소는 인접하지 않은 레이어의 구성요소를 볼 수 없어야한다.
- Code-On-Demand (Optional) – 서버가 네트워크를 통해 클라이언트에 프로그램을 전달하면 그 프로그램이 클라이언트에서 실행될 수 있어야한다. (Java applet이나 Javascript 같은 것을 말함) 다만 이 제약조건은 필수는 아니다.
RESTful 하게 API 를 디자인 한다는 것은 무엇을 의미하는가.(요약)
- 리소스 와 행위 를 명시적이고 직관적으로 분리한다.
- 리소스는
URI로 표현되는데 리소스가 가리키는 것은명사로 표현되어야 한다. - 행위는
HTTP Method로 표현하고,GET(조회),POST(생성),PUT(기존 entity 전체 수정),PATCH(기존 entity 일부 수정),DELETE(삭제)을 분명한 목적으로 사용한다.
- Message 는 Header 와 Body 를 명확하게 분리해서 사용한다.
- Entity 에 대한 내용은 body 에 담는다.
- 애플리케이션 서버가 행동할 판단의 근거가 되는 컨트롤 정보인 API 버전 정보, 응답받고자 하는 MIME 타입 등은 header 에 담는다.
- header 와 body 는 http header 와 http body 로 나눌 수도 있고, http body 에 들어가는 json 구조로 분리할 수도 있다.
- API 버전을 관리한다.
- 서버와 클라이언트가 같은 방식을 사용해서 요청하도록 한다.
- 브라우저는 form-data 형식의 submit 으로 보내고 서버에서는 json 형태로 보내는 식의 분리보다는 json 으로 보내든, 둘 다 form-data 형식으로 보내든 하나로 통일한다.
- 다른 말로 표현하자면 URI 가 플랫폼 중립적이어야 한다.