1 - 웹 애플리케이션 이론

GET과 POST 메소드

폼에서 사용자가 입력한 데이터를 서버로 보낼때 방식

• GET방식 = 파라미터들을 URL 부분 ? 뒤에 <이름=값>으로 보냄
  URL의 길이 제한 -> 많은 양의 데이터 보내기 어려움 / 주소창에 노출 -> 보안 측면에서도 불리
• POST방식 = 파라미터들을 request 메세지의 바디에 넣어 보냄
  보통 폼을 사용할때에는 POST방식을 사용(잔고 프레임워크는 POST방식만을 지원)

상태 코드 : 코드를 통해 요청에 대한 처리 상태를 이해할 수 있음
3자리 숫자로 되어 있는데, 첫 번째 숫자는 HTTP 응답 종류 구분에 사용
1xx - 임시적인 응답, 현재 클라이언트의 요청까지 처리되었으니 계속 진행하라는 의미
2xx - 클라이언트 요청이 성공적으로 처리
3xx - 리다이렉션 - URL이 이동되었으니 그 주소로 다시 해보라는 의미
4xx - 클라이언트 에러 - 클라이언트 요청 메세지 내용이 잘못된 경우 ( 없는 페이지 요청 )
5xx - 서버 에러 - 서버 에서 요청 메세지 처리에 문제가 발생한 경우

 

---

 

URL 설계 : 웹 애플리케이션 개발시 요구사항에 따라 디자인 측면에서는 화면 UI를, 프로그램 로직 측면에서는 URL을 설계
URL 구성 : URL 스킴(프로토콜)//호스트명+포트번호/경로?쿼리스트링#프라그먼트

URL을 바라보는 측면

RPC(Remote Procedure call) : 클라이언트가 서버가 제공하는 API함수를 호출하는 방식
URL과 API설계를 동일하게 고려 -> 경로를 API함수명으로 + 인자를 쿼리스트링으로 지정
ex) http://blog.example.com/search?q=test&debug=true
REST(Representational State Transfer) : 웹 서버에 존재하는 모든 요소들을 리소스라고 정의(즉, 모든 요소들이 별도의 경로[리소스]를 가짐)
리소스에 대한 조작을 HTTP 메소드를 통해 구분
ex) http://blog.example.com/search/test +GET 메소드 사용
최근에는 REST방식이 더 인기가 좋음
간편 URL : 사용자에게 친숙한 URL = 특수문자들이 없는 URL = 쿼리스트링없이 경로만 가진 URL => 파이썬 프레임워크는 이것을 지원

 

---

웹 서버 vs 웹 애플리케이션 서버

웹 서버 : 클라이언트의 요청을 받아 처리하고 그 결과를 클라이언트에게 응답 ( 주로 정적 페이지 처리 )

웹 애플리케이션 서버 : 웹 서버로부터 동적 페이지 요청을 받아 처리하고 그 결과를 웹 서버로 반환 

( 주로 동적 페이지 생성을 위한 프로그램 실행과 DB 연동 기능 처리 )

 

정적 페이지 vs 동적 페이지

정적 페이지 : 누가 언제 요구하더라도 항상 같은 내용을 표시하는 웹 페이지 ( 동일한 리소스 요청 -> 동일한 페이지 반환 )

동적 페이지 : 프로그래밍 코드가 포함되어있어 페이지 요청 시점에 HTML 문장을 만들어내는 페이지

  웹 서버와는 다른 별도의 프로그램이 필요 => 별도의 프로그램과 웹 서버 사이에 정보 교환 규칙 CGI 규격탄생

CGI 방식의 단점

CGI 규격만 준수하면 어떤 언어로든지 CGI 프로그램을 만들 수 있음

문제점 : 요청에 대하여 독립적인 별도의 프로세스가 생성 => 프로세스가 많아져 시스템에 부하를 줌

그래서 현재는 CGI 방식을 거의 사용하지 않음

 

CGI 방식의 대안 기술

책 p.39

 

웹 애플리케이션 서버 방식

웹 서버와 역할을 구분하여 사용하는 것이 좋음( 동적 페이지를 처리하는 경우 메모리 소모가 큼 )

즉, 웹 서버는 정적 페이지만 처리 / 웹 애플리케이션은 동적 페이지만 처리

 

웹 서버는 그 외에도 캐시, 프록시 기능 / 접속 허가 클라이언트 수의 제한 및 처리 프로세스 관리 등 여러가지 기능 존재