* 형광펜 표시한 부분은 크로스체킹이 필요한 부분이라 읽을 때 주의가 필요합니다.
목차
1. 웹 애플리케이션 아키텍쳐
1-1. 클라이언트 - 서버 아키텍처
1-2. 클라이언트 - 서버 통신 과 API
1-2-1.프로토콜
1-2-2.API
1. 웹 애플리케이션 아키텍쳐
1-1. 클라이언트 - 서버 아키텍처
서버간의 통신을 서버와, 클라이언트로 분리시킨 설계방식입니다. 2티어 아키텍처라고 부르기도 하며 3티어 아키텍처는 데이터베이스가 추가된 설계방식을 의미합니다. 클라이언트와 서버와의 통신은 요청과 응답으로 구성되며 요청이 있어야만 응답이 옵니다.
1-2. 클라이언트 - 서버 통신 과 API :
1-2-1.프로토콜
요청과 응답은 이미 정해진 일련의 규칙에 맞게 요청을 해야 잘 작동하며 서버는 정해진 양식으로 응답합니다. 이때 통신시 정해진 약속과 규약을 프로토콜(통신규약)이라 말합니다. 프로토콜의 종류 중에는 대표적으로 HTTPHypertext Transfer Protocol가 있고 하이퍼 텍스트(웹페이지뿐만 아니라 이미지,문서들을 포괄적으로 포함하는 리소스의 개념입니다. 를 전송할 때 프로토콜(지켜야하는 통신규약)입니다.
그렇다면 클라이언트(사용자)는 서버에 요청("나 네이버페이지 보고 싶어")을 할 때 프로토콜을 지키며 요청해야 합니다. 어떻게 프로토콜(통신규약)을 지키면서 요청할 수 있을까요? 사용자는 우리가 흔히 알고 사용하는 URL (더 정확히는 URI)을 통해 프로토콜을 지키며 요청할 수 있습니다.
프로토콜(통신규약)의 종류
프로토콜 이름 | 설명 | OSI 7 Layers |
HTTP | 하이퍼 텍스트(웹페이지)를 전송할 때 프로토콜(지켜야하는 통신규약) | 7. 응용 계층 |
HTTPS | HTTP + 보안 강화= https 통신규약 | |
FTP | 파일 전송 시 지켜야하는 통신규약 | |
SMTP | 메일 전송 | |
SSH | CLI 환경(like 터미널창)의 원격 컴퓨터에 접속시 Q.무슨의미 | |
RDP | windows 계열의 원경 컴퓨터 접속시 Q.무슨의미 | |
WebSokct | 실시간 통신, push 등 사용시 Q.무슨의미 |
프로토콜 이름 | 설명 | OSI 7 Layers |
TCP | HTTP와 FTP 통신 등의 근간이 되는 통신규약 (양방향) | 4. 전송 계층 |
UDP | 단방향 통신규약(더 단순,빠른 속도, 낮은 신뢰성) |
*TCP와 HTTP
* TCP 와 HTTP
- 데이터 형태
- tcp: byte Array로 정보를 통신
- http: String으로 정보를 통신
http 통신규약을 통해 문자열로 만들어진 http 메시지는 또 몇단계의 과정에 거쳐 서버에 전달하게 되는데 그 다음 단계중 tcp라는 통신규약을 거쳐 요청메시지를 더 세밀하게 쪼개고 송수신합니다.
1-2-2. API
정리하자면 클라이언트는 URI로 프로토콜을 지켜 서버에게 요청할 수 있습니다. 단순히 "네이버 대표홈페이지 들어가줘"라는 요청은 해당 홈페이지의 도메인(naver.com)만 알면 쉽게 요청할 수 있지만 더 다양한 행동으로 더 자세하게 요청할 수 도 있습니다. URL을 통해 사용자가 직접 " 네이버 웹툰 중 안녕,나의수집 페이지를 보여줘 "라는 요청을 서버에게 보낼 수 있습니다. 네이버 검색창이 있는 데 굳이 이렇게 사용할까란 생각이 드나요? 조금 시야를 넓혀봅시다. 일반 사용자가 아닌 개발자 시각에서 웹사이트를 만들 때 부분적으로 네이버 지도를 자신이 만든 페이지 일부영역에 보여주고 싶습니다. 이럴 때는 네이버의 검색창으로 해당 페이지를 불러오기 어렵습니다.
돌아가서 예시와 같은 요청" 네이버 웹툰 중 안녕,나의수집 페이지를 보여줘 "을 하려면 아래 사진과 같은 상세하고 복잡한 주소를 기억해 이용하면 됩니다. 하지만 우리는 URI 주소를 일일이 기억할 수 없고 서버가 어떻게 구성되어 있는지 (안녕,나의 수집 1화페이지는 코믹네이버페이지 안에 웹툰안에 있는 서버의 구조)알 방법이 없습니다. 우리가 서버 코드를 직접 짠 사람도 아닌데, 어떻게 사용 가능한 자원(홈페이지나 데이터)을 파악할 수 있을까요? 바로 API로 해결할 수 있습니다.
클라이언트가 리소스(홈페이지,데이터)를 잘 활용할 수 있도록 서버는 클라이언트에게 서버의구조를 알려주는 API를 제공해야합니다. 이를 통해 요청에 대한 URL 를 찾을 수 있고 이를 활용할 수 있습니다. 그리고 더 나아가 홈페이지를 띄우는 것말고 더 다양한 행동을 할 수 있습니다. 클라이언트가 서버의 데이터를 삭제하거나 추가할 수 도 있습니다. HTTP 요청에는 메서드라는 것이 존재하는데 그중 대표 다섯 가지 메서드는 다음과 같습니다. GET, POST, PUT(또는 PATCH), DELETE 각각 조회, 추가, 갱신, 삭제와 관련이 있습니다. 그래서 API작성시 API안에 하려는 행동에 맞게 HTTP 메서드를 적절히 작성해야 합니다. 만일 GET 요청을 했는데 갑자기 서버에서 리소스가 지워진다면 좋은 API 디자인이라고 볼 수 없습니다.
HTTP 상태 코드 분류
분류 | 내용 |
1 xx Informational (조건부 응답) | 정보 요청을 했지만 여전히 처리 중임을 나타냅니다. |
2 xx Successful (성공) | 성공적으로 요청/응답 했음을 나타냅니다. |
3 xx Redirection (리디렉션) | 요청한 리소스(웹페이지등)가 일시적/영구적으로 이동되었음을 나타냅니다. |
4 xx Client Error (요청 오류) | (내 잘못 )클라이언트의 잘못된 요청으로 서버가 이해를 못해 |
5 xx Client Error (서버 오류) | (니 잘못) 요청은 잘했지만 서버 오류로 인해 정상 처리 못했음을 나타냅니다. |