REST API의 탄생
REST API는 Representational State Transfer API로 웹 서비스간의 통신을 위한 규칙이다.
웹이 성장해 시스템간의 통신이 많아지고 여러 언어, 플랫폼, 운영체제가 마다 인터페이스가 달라져 데이터 공유가 어려워지기 시작했다. 이 때 클라이언트와 서버의 역할을 분리해 서로 의존성을 낮추고 개발과 유지보수를 효율적으로 하기위해 REST API 개념이 등장했다.
REST API 특징
- 인터페이스: 리소스 조작을 통일된 인터페이스로 수행, 각 자원마다 내용을 URI에 표현해 식별한다. (행위는 uri에 X)
- HTTP 메서드(Methods): REST API에서 자원에 대한 작업을 HTTP 메소드를 통해 표현하며 내용은 다음과 같다.(GET, POST, PUT, DELETE)
- 표현(Representation): . 클라이언트와 서버 간에 주고받는 자원의 형태는 JSON, XML, HTML 등 다양한 형식으로 표현될 수 있다.
- 상태 없음(Statelessness): REST는 상태를 관리하지 않는 것을 원칙으로해 클라이언트의 각 요청은 모든 필요한 정보를 포함해야 하며, 서버는 이전 요청과 관련된 상태 정보를 저장하지 않는다. 이로써 클라이언트와 서버 간의 의존성이 줄어들고, 서버는 다양한 클라이언트들로부터 독립적으로 요청을 처리할 수 있습니다.
- 캐시 (Caching): 클라이언트는 서버로부터 받은 응답을 캐시하여 저장해 저장된 응답은 나중에 동일한 요청을 할 때 재사용될 수 있다. 이는 네트워크 부하를 줄여 응답시간을 줄인다.
- 계층 구조 (Layered System): 클라이언트는 직접 서버와 통신하며, 필요에 따라 중간에 프록시 서버, 게이트웨이, 로드 밸런서 등의 중간 계층을 사용할 수 있다. 이러한 계층 구조를 통해 보안, 로드 분산, 캐싱 등의 기능을 추가하거나 관리할 수 있다.
URI설계시 주의점
- 슬래시 구분자(/)는 계층관계를 나타냄(
http://restapi.example.com/animals/monkey) - URI의 마지막에 구분자를 사용하지 않는다. 식별자 혼동을 방지(
http://restapi.example.com/animals/monkey/ - URI경로가 길어진다면 URI에 하이픈(-)을 추가해 가독성을 높이자. (
http://restapi.example.com/time-series) - 가독성을 위해 URI에 밑줄(_)은 사용하지 말자. (
http://restapi.example.com/time_series - URI 경로에는 소문자를 사용하자. (URI문법형식에 따라 스키마와 호스트를 제외하고는 대소문자를 구분하도록 규정하기 때문.)
- 파일 확장자를 URI에 포함시키지 않고 Accept 헤더를 사용해서 보낸다. (
http://restapi.example.com/animals/monkey.jpg) - URI 구분자 오른쪽으로 갈 수록 하위 개념(도큐먼트)로 표시
주로 쓰이는 응답의 상태코드종류
- 2xx 성공
- 4xx 클라이언트의 요청이 잘못됨
- 5xx 서버의 내부에서 오류가 발생
Reference
러닝커브를 빠르게 높이자🎢