RESTful API
Representational State Transfer의 약자이다. 인터넷상의 자원을 정의하고 자원에 대한 주소를 지정하는 방법 전반에 대한 패턴
6가지 원칙
1. Client-Server
- client application과 server application은 반드시 서로간의 의존성 없이 개발되어야한다. client는 오직 URI만을 알고있어야한다.
2. Stateless
- 서버는 클라이언트가 요청한 HTTP request에 대해서 아무것도 저장해서는 않는다.
- 만약 클라이언트 앱이 stateful application이라면, 요청을 보낼때마다 필요한 정보들을 포함해야한다.
3. Cacheable
- 데이터나 응답을 가능하다면 캐싱을 한다. 왜냐하면, 캐싱은 성능향상과 server에 대한 확장성을 증가시키기 때문이다.
- 캐싱가능한 리소스들은 Cacheable이라고 명시해야한다.
- 캐싱은 server 또는 client에서 구현될수 있다.
4. Uniform Interface
- 자원들에대한 api 인터페이스를 결정하고 그것을 충실히 따라야한다.
- 자원은 오직 하나의 논리적 URI를 가져야하고, 관련된 또는 추가적인 데이터를 fetch할 방법을 제공해야한다.
- 모든 자원들은 HTTP GET(또는 수정된 버전)과 같은 흔한 접근방법으로 일정하게 접근될수 있어야한다.
5. Layered System
- REST는 layered system architecture(예를들면, API는 serverA에 실행, data는 serverB에 저장, 요청을 검증하는 것은 serverC에서 함)를 허용하는데, 클라이언트는 end server에 연결되었는지 매개체에 연결되었는지 알수없다.
6. Code on demand(optional)
- 대부분은 XML이나 JSON형태로 리소스들에 대한 정적인 표현으로 응답하게되지만, application의 일부를 지원하기 위해 executable code를 보낼수도 있다.
- 예를들면, 클라이언트는 UI widget rendering code를 얻기위해서 api를 호출할수 있다.
위의 제약사항들은 truly RESTful API를 만드는데 도움이되고 따라야하지만, 몇개를 지키지 않았다고 해서 걱정할 필요는 없다. 여전히 RESTful API를 구현하고 있는 것이지만, truly RESTful하지는 않다.