오늘 한 일

스프링 프로젝트 빌드

• 강의에선 mac 환경에서 빌드하는거라 윈도우랑 조금 다름
• 윈도우에서 spring빌드

1. cmd : 프로젝트 위치로 이동

• 처음 cmd를 열면 C드라이브로 되어있다. D:를 입력해 D드라이브로 이동 후 cd 경로 로 프로젝트 위치로 이동한다.

2. gradlew.bat 파일 있는지 확인

3. cmd에 gradlew build 입력

4. /build/libs 폴더로 이동

5. snapshot. jar 파일 생성 확인

6. java -jar 프로젝트명-snapshot 입력 (실행)

• 앞글자 일부 입력 후 tab키 누르면 파일명 자동 입력

7. 빌드 후 구동 확인

• 추후 별도 서버에서 구동 시 해당 jar파일만 복사해서 구동하면 된다고 함 (아마 jdk, db같은건 별도로 설치해주어야될듯?)
  

8. build 잘 안되었을때 재실행

• gradlew clean build : 기존 build된 파일 삭제 후 다시 실행

http 강의 수강

• 인프런 모든 개발자를 위한 HTTP 웹 기본 지식 수강 중

인터넷 프로토콜 (IP)

• 지정한 IP 주소로 데이터 전달
• 데이터 전달 시 패킷이라는 통신 단위 사용
• IP 패킷 정보 : 나의 ip, 목적지 ip

IP 프로토콜의 한계 => TCP/UDP

• 비연결성 : 패킷 받을 대상이 없거나 서비스 불능이어도 패킷 전송
• 비신뢰성 : 중간에 패킷이 사라지면? 순서대로 안 오면?(보통 1500바이트 이상 되면 패킷을 여러 개로 나누어서 보냄)
• 프로그램 구분 : 같은 IP 서버에서 통신하는 애플리케이션이 둘 이상이면?

TCP (transmission control protocol 전송제어 프로토콜)

• tcp 세그먼트 정보 : 출발지 port, 목적지 port, 전송제어, 순서, 검증정보...
• 신뢰할 수 있는 프로토콜이라 대부분 TCP 사용

TCP 특징

• 연결지향 : TCP 3 way handshake (연결 확인 후 메시지 전송)
• 데이터 전달 보증
• 순서 보장

1. TCP 3 way handshake 연결과정

1) 클라 -> 서버 : syn
2) 서버 -> 클라 : syn + ack
3) 클라 -> 서버 : ack (+data)
4) 서로 데이터 전송

• 물리적 연결 아니고 논리적 연결 (중간 노드들은 연결 여부 모름)

2. 데이터 전달 보증

1) 클라 -> 서버 데이터 전송
2) 서버 -> 클라 : 데이터 잘 받음

3. 순서 보장

1) 클라 -> 서버 : 패킷 1, 2, 3 순서로 전송
2) 서버 : 패킷 1, 3, 2 순서로 도착
3) 서버 -> 클라 : 잘못 온 두번째 패킷부터 다시 보내라는 요청

UDP (User Datagram Protocol)

• UDP = IP + port + 체크섬(데이터 검증)
• 데이터 전달 및 순서 보증 안되지만 단순하고 빠름
• http/3 에서 사용

PORT

• 하나의 컴퓨터 (IP주소)에서 여러 응용 프로그램들이 요청 보내는 경우 프로세스 구분하기 위한 주소값

URI vs URL vs URN

• URI (Uniform Resource Identifier) = URL + URN : 자원이 어디에 있는지, 자원 자체를 식별하는 통일된 방식
• URL (Uniform Resource Locator) : 리소스의 위치
• URN (Uniform Resource Name) : 리소스의 이름

URI

scheme://[userinfo@]host[:port][/path][?query][#fragment]
https://www.google.com:443/search?q=hello&hl=ko

• host : 도메인명, ip 직접 사용 가능
• query : key=value 형태. ?로 시작, &로 연결
• html 내부 북마크 등에 사용. 서버에 전송되지 않는 정보

HTTP 메서드의 속성

1. 안전 (safe)

• 호출해도 대상 리소스에 변화를 일으키지 않음
• get 조회는 안전, post, patch, delete등은 안전하지 않음

2. 멱등 (idempotent)

• 한번 호출하든 100번 호출하든 결과가 같은 속성
• GET, PUT. DELETE : 멱등함
• POST : 멱등하지 않음. 여러 번 호출 시 같은 객체 여러 번 생성될 수 있음
• 자동복구 메커니즘 : 서버가 정상응답 못했을 때 클라이언트가 같은 요청을 다시 해도 되는가? 판단 근거

3. 캐시 가능

• 응답 결과 리소스를 캐시해서 사용해도 되는가?
• GET, HEAD, POST, PATCH 캐시 가능
• 실제로는 GET, HEAD 정도만 캐시로 사용

HTTP API 설계 예시

1. POST 등록 기반

• 클라이언트는 생성하는 리소스 URI 주소값 모름
• 서버에서 신규 리소스 식별자 생성

2. PUT 등록 기반

• ex. 파일관리 시스템.
• URI에 사용될 파일명을 클라이언트가 알고 있음
• 기존 파일 있으면 삭제하고 올려야 함

3. HTML form 사용 : GET, POST만 지원

• ajax등을 이용해 해결 가능 (회원 API 참고)
• control url 사용 (/new, /edit, /delete 등 동사형)
• 컬렉션 (Collection) : 서버가 관리하는 리소스 디렉토리로 리소스 URI를 생성하고 관리함. 여기서 컬렉션은 /members
• REST 리소스 네이밍 가이드

api 주소 작성

1. html form 사용 버전

2. post 등록 버전