Server: (client 컴퓨터에서 오는 요청에 대한 응답으로)data를 주는 컴퓨터. Server 컴퓨터가 linux(OS)위에서 server program(Web Server, Web Application Server, 등등)을 돌린다.
Web Server: 일반적으로 HTML과 같은 정적 파일들을 전달해주는 역할을 하는 서버
Web Application Server(WAS): PHP, JSP, ASP와 같은 언어들을 사용해서 동적인 페이지들을 생성 할 수 있는 서버 (Java 계열에서는 web application server를 web application container라고 한다)
WAS의 종류:
-GlassFish
-JBoss
-Jetty
-JEUS
-Resin
-WebLogic
-WebSphere
WAS분석 시, 고려 사항:
-가용성
-성능
-기술 지원
-구축 비용
Web Application Container는 WAR 파일의 WEB-INF 폴더를 기중으로 클래스 파일들을 로드한다.
WAR(Web Application Archive 또는 Web Application Resource): webapp 또는 web이름으로된 폴더를 포함한다. webapp는 정적자원(HTML, Javascript, CSS, HTML태그를 포함하고있는 JSP파일과 같이 프라우저에 보여줘야하는 정적자원)을 관리하기 위한 폴더이다. 최근에는 WEB-INF 하위 classes 폴더에 WAR로 패키징한 파일들을 저장하는 추세이다.
Web Application Class loader는 JVM의 hierarchical class loaders 유형중에서 가장 하위 class loader인 system class loader 하위에 User-defined class loader에 해당한다.
여기서 잠시 JVM class loader관련 review: JVM에는 3가지 유형의 class loader가 있다. Hierarchy 왕부모부터 순서대로:
(1) Bootstrap(JVM runtime 실행을 위한 기반이 되는 파일들 로드(e.g., rt.jar))
--> (2) Extension(Java객체의 최상위 객체인 Object 포함 Java API 로드)
--> (3) System(class path에 포함된 classes 로드. 로컬에서 외부 라이브러리 사용위해 사용자가 class path 지정하기도. 독립적 영역이 필요한 WAS의 경우 "User-defined class loader" 만들어서 사용함)
Web application container는 web application 자체 API를 제공하기위해 container를 로드하는 class loader와 사용자가 추가한 JSP나 WAR파일들을 다루기 위한 ServletContextLoader를 사용한다. Container가 시작되고 초기화되면서 servlet 스펙의 권장사항에 따라 WEB-INF/classes 파일들을 먼저 검색해서 loading하고, 그 후 WEB-INF/lib에 있는 jar (라이브러리) 파일들을 loading한다.
Servlet: JVM기반에서 web개발을 하기위한 API이다. Java를 실행하려면 JRE(JRE=JVM+libraries)가 필요하듯이 servlet을 실행하려면 web application container가 필요하다. Servlet은 Java EE에 포함된 spec중에 하나로 Java에서 HTTP요청과 응답을 처리하기위한 내용을 담고있다.
API: Application Program Interface
응답을 보내는 쪽에서(서버 프로그램) API를 만든다. 요청을 보내는쪽은(클라이언트/사용자)는 API를 활용해서 (필요한 응답을 받기위해) 요청을 보내는것이다.
클라이언트(또는 요청을 보내려는 software에서)요청을 보낼때 Server에게 어떻게 요청을 보내야 하는지를 server에서 미리 체계를 만들어 놓는것이다. 어디로 어떤 주소로 요청을 보낼지 정해진 체계를 따르면, server(또는 요청에 대한 응답자원을 가진 software)가 적절한 응답을 보낼 수 있다.
API 문서에는 Request와 Response 각각의 내용이 정의되어있다.(Request에는 PathParameters, Headers, Query Parameters, 등. Response에는 200, 404등 response page를 구현할 내용, 데이터, 등)
RESTful API
좀 더 체계적으로 API를 관리하기위해 RESTful API를 사용한다. RESTful API를 사용하면, 기존 API를 사용하는 체계에서보다 주소 개수가 줄어든다. RESTful API를 사용하면, CRUD를 하나의 주소로 관리한다. 단 하나의 주소로 요청을 보낼때에 어떤 요청을 보내는지를 method로 구분시킨다. (일종에 구분할 수 있는 POST,GET,PUT,PATCH,DELETE가 적힌 스티커를 붙여 요청 편지(요청 주소)를 보내는것이다)
*주요 method의 용도:
C(Create): POST
R(Read): GET
U(Update) : PUT(전체)/PATCH(일부)
D(Delete) : DELETE
요청 처리 결과(응답 페이지)의 종류
200번대: 응답 받아오기 성공
400번대: 클라이언트 쪽에서 요청을 보낼때 뭔가 잘못됨 (e.g., 404: 정의되지 않은 요청이다. 서버에 없는 정보를 클라에서 요청했을때)
500번대: 서버 쪽에서 요청 처리 후 응답을 보낼때 뭔가 잘못됨
References
- 스프링부트로 배우는 자바 웹 개발 (JPub) -윤석진 지음
- 비전공자를 위한 이해할수있는 IT 지식 (T.W.I.G) - 최원영 지음
