[Frontend 기술 면접 대비] 시리즈는 Frontend 개발자로 취업하기 위해 내 프로젝트 경험과 지식들을 정리한 내용이다.
REST 구성 요소
- Resource(자원) - URI
- 모든 자원에 고유한 ID가 존재하고, 이 자원은 Server에 존재한다.
- 자원을 구별하는 ID는 HTTP URI이다.
- Client는 URI를 이용해서 자원을 지정하고, 해당 자원의 상태에 대한 조작을 Server에 요청한다.
- Verb(행위) - HTTP method
- HTTP 프로토콜의 method(
POST
,GET
,DELETE
,PUT
)를 사용한다.- Representation(표현)
- Client가 자원의 상태에 대한 조작을 요청하면 Server는 이에 대해 응답(표현)을 보낸다.
- 자원은
JSON
,XML
,TEXT
,RSS
등으로 표현되어 나타내질 수 있다.JSON
혹은XML
을 통해 전달하는 것이 일반적이다.
REST 아키텍처에 적용되는 제한 조건(특징)
- 인터페이스 일관성: URI로 지정한 Resource에 대한 조작은 통일되고 한정적인 인터페이스로 수행한다.
- 무상태(Stateless): 각 요청 간 클라이언트의 context가 Server에 저장되어서는 안 된다. Server는 각각의 요청을 완전히 별개의 것으로 인식하고 처리한다. Seerver의 처리방식에 일관성을 부여하고 부담이 줄어들며, Server의 자유도가 높아진다.
- 캐시 처리 가능(Cacheable):
www
에서와 같이 Client는 응답을 캐싱할 수 있어야 한다.- 계층화(Layered System): Client는 REST API Server만 호출한다. REST Server는 다중 계층으로 구성될 수 있다. 로드밸런싱, 공유 캐시 등을 통해 확장성과 보안성을 향상시킬 수 있다.
- Code on demand(Optional): Java applet이나 JavaScript를 제공해 Server가 Client가 실행시킬 수 있는 로직을 전송하여 기능을 확장시킬 수 있다.
- Client/Server 구조: 자원이 있는 쪽이 Server, 자원을 요청하는 쪽이 Client가 된다. 아키텍처를 단순화시키고 작은 단위로 분리함으로써 Client-Server의 각 파트가 독립적으로 개선될 수 있도록 해준다.
REST에서 가장 중요한 중심 규칙 2가지
장점
- HTTP 프로토콜의 인프라를 그대로 사용하므로 REST API 사용을 위한 별도의 인프라를 구축할 필요가 없다.
- HTTP 표준 프로토콜을 따르는 모든 플랫폼에서 사용 가능하다.
- API가 의도하는 메시지를 쉽게 파악할 수 있다.
- Server와 Client의 역할을 명확하게 분리한다.
단점
- 표준이 존재하지 않는다.
- 사용할 수 있는 method가 제한적이다.
- 구형 브라우저가 아직 지원하지 못하는 부분이 있다.
REST API 설계 원칙
- URI는 명사를 사용한다.
/
로 계층 관계를 표현한다.- URI 마지막 문자로
/
를 포함하지 않는다.- URI는 소문자로만 구성한다.
- HTTP 응답 상태 코드를 사용한다.
- 파일확장자는 URI에 포함하지 않는다.
개발 공부를 하고 프로젝트를 하기 전부터 REST API의 중요성을 들었다. 하지만, 막상 프로젝트에서 사용하는 API 요청과 HTTP method 들이 REST API의 요소라는 것을 인지하지 못했다. 프로젝트를 진행하면서 많은 URI 들을 다루다보니, 각 요청이 뜻하는 바를 명확하게 하기 위해 설계 단계에서 URI의 이름이나 계층 구조에 대해 집중했다. 나아가, 어떤 응답 코드를 반환하고 Header나 Params에 어떤 정보가 들어가야 하는지 고민했다. API가 RESTful해질수록 Client와 Server 사이에 정보를 주고받는 과정에서 혼동이 덜 발생하는 것을 느꼈다.
함께 보면 좋은 글