[CS] - Network(3)
REST API
- REST는 Representational State Transfer의 약자이다.
- HTTP URI로 자원을 명시하고, HTTP 메서드를 통해 자원의 상태를 주고 받는 것 을 의미한다.
- 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하므로 웹의 장점을 최대한 활용가능한 아키텍쳐이다.
구성
REST api 는 다음의 구성으로 이루어져 있다.
- 자원(RESOURCE) - URI
- 행위(Verb) - HTTP METHOD
- 표현(Representations) - JSON, XML, text, RSS 등 여러 형태의 표현식.
REST API 설계 기본 규칙
- Uniform, 유니폼 인터페이스
- URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행한다.
- Stateless, 무상태성
- 작업을 위한 상태정보를 따로 저장 혹은 관리하지 않는다.
- 서버는 클라이언트의 이전 상태를 알지 못하며, 모든 요청이 독립적으로 처리된다.
- Cacheable, 캐시 가능
- HTTP의 기본적인 캐싱 기능을 그대로 사용 가능하다.
- 서버에서 캐시 가능한 응답에 적절한 캐시 헤더를 추가해 캐시 가능한 리소스를 알려주는 것이 좋다.
- Self-Descriptiveness
- REST는 메시지 자체가 어떤 작업 수행하는지 명확하게 알 수 있도록 만들어짐.
- Server-Client 구조
- Server(자원 제공), Client(자원 요철)
- 서버는 api를 제공하고 비즈니스 로직 처리 및 저장을 책임진다.
- 클라이언트와 서버 간 의존성을 최소화하고 독립적으로 개발 가능한 환경 제공
- 계층형 구조
- 서버는 다중 계층으로 구성될 수 있다.
- 중간 계층은 로드 밸런싱, 공유 캐시, 보안, 암호화 등을 처리할 수 있다.
- PROXY, 게이트웨이 같은 네트워크 기반의 중간 매체를 사용할 수 있게 한다.
API 디자인
URI 설계 원칙
-
URI는 정보의 자원을 표현해야 하며, 자원을 표현하는 데에는 명사를 사용한다.
-
자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE 등)로 표현한다.
-
슬래시(/)는 계층 관계를 나타내는 데 사용한다.
RESTapi URI 설계 규칙
-
URI 마지막 문자로 슬래시(/)를 포함하지 않는다.
-
하이픈
-은 URI 가독성을 높이는 데 사용하며, 언더바_는 사용하지 않는다. -
URI에는 소문자를 사용한다.
-
파일 확장자는 URI에 포함시키지 않는다.
http://api.example.com/device-management/managed-devices.xml /*Do not use it*/
http://api.example.com/device-management/managed-devices /*This is correct URI*/
기본 규칙은 REST API 설계 시 가장 중요한 핵심 원칙이며, 일반적인 규칙은 API의 가독성과 일관성을 높이는 데 도움이 된다. 기본 규칙과 일반적인 규칙을 모두 고려하여 설계하면 RESTful한 API가 된다.
web server vs WAS(Web Application Server)
web server
- 웹 서버는 정적인 웹 콘텐츠를 제공하며, HTTP 응답을 웹 브라우저로 보낸다.
- 이미지, HTML&CSS 등 단순한 정적인 리소스들만을 전달하고자 할때 이용하면 빠르고 안정적으로 기능을 수행할 수 있다.
- 예 : Apache, Nginx, IIS
WAS
- 어플리케이션 서버는 동적인 요청을 받아 처리해주는 서버이다.
- Web Server + Web Container
- 웹 앱과 서버 환경을 만들어 동작시키는 소프트웨어이다.
- DB와 연결되어 사용자와 데이터를 주고받으며 조작이 필요한 경우 WAS를 활용한다.
- 예 : Tomcat, JBoss, Jeus, Web Sphere, Glassfish 등
웹서버에서 수행할 수 있는 것을 WAS에서 전부 수행 가능하다면 웹서버는 굳이 사용할 필요가 있는가?
- 정적인 콘텐츠 요청까지 WAS에서 처리하게 되면 동적 컨텐츠 처리가 지연되며 서버 부하가 커지게 되어 효율성이 떨어지게 된다. (필요에 따라 알맞게 선택하여 사용하자)
- 따라서 목적에 맞게 분리해 사용해 WAS 서버 부하를 줄일 수 있다.
CORS (Cross-Origin Resource Sharing)
- 브라우저가 추가 HTTP 헤더를 사용해, 한 곳에서 실행 중인 웹 앱이 다른 곳의 선택된 자원에 접근할 수 있는 권한을 부여하도록 브라우저에 알려주는 체제이다.
- 도메인/호스트/포트 등을 공유하지 않는 사이트들에 대해 화이트리스트를 사용하는 것과 같다.
요청 유형
- CORS에는 다음과 같은 두 가지 유형의 요청이 있다.
1. Simple Requests
- 요청 메소드가 GET, POST, HEAD 중 하나
- 사용자 지정 HTTP 헤더를 제외한 추가적인 요청 헤더가 없는 요청을 말한다.
- 서버는 이러한 요청에 대해 추가 검증없이 요청을 처리한다.
2. Preflighted Requests
- 요청 메소드가 GET, POST, HEAD 외의 다른 메소드이거나 사용자 지정 HTTP 헤더를 포함한 요청일 때
- 사전 요청은
OPTIONS메소드를 사용하며, 서버는 이에 대한 응답을 보내게 된다. - 브라우저는 이 응답을 확인하고, 서버로 실제 요청을 보내기 전에 해당 요청의 내용이 안전한지 여부를 결정한다.
인증된 요청과 와일드카드
- 와일드카드(*)를 사용해 모든 도메인에서의 요청을 허용할 수 있으나, 이는 보안상 위험할 수 있으므로 일반적으로는 요청을 보내는 도메인을 명시해 인증된 도메인에 대해서만 접근을 허용하는 것이 좋다.
출처
- URI naming conventions
- REST API 제대로 알고 사용하기
- https://www.ibm.com/topics/web-server-application-server
- 웹 서버와 WAS
Leave a comment