그냥혀유 그냥혀유

1. 프론트 컨트롤러 패턴 소개 - FrontController 패턴의 특징 > 하나의 서블릿으로 클라이언트 요청 받기 > 요청에 맞는 컨트롤러 찾아서 호출 (pojo) > 입구를 하나로 만드는 것이 핵심 (공통처리,pojo를 활용한 확장성 스프링 MVC의 핵심은 FrontController이다. 2. 프론트 컨트롤러 V1 v1의 구조 - V1의 핵심은 서블릿 1개로 만들고 컨트롤러 분리해서 처리하기이다. - 기존 프론트 컨트롤러에 맵핑과 서블릿과 비슷한 모양의 컨트롤러 인터페이스 도입 -컨트롤러 v1 public interface ControllerV1{ void process(HttpServletRequest request, HttpServletResponse respon..

- 서블릿과 jsp만을 사용해서 웹 어플리케이션을 구성해보고, 간단한 MVC 패턴을 활용해보자 1. 회원 관리 웹 어플리케이션 요구사항 //회원 도메인 @Getter @Setter public class Member{ private Long id; private String username; private int age; public Member(){} public Member(String username, int age){ this.username = username; this.age = age; } } //회원 저장소 public class MemberRepository{ private static Map store = new HashMap(); private static long sequence =..

- 서블릿 생성방법, HttpServletRequest와 Response에 대해서 알아보자 - reqeust는 HTTP 요청 메시지 파싱한 결과 담김 -> 편리하게 조회 - response는 HTTP 응답 메시지 쉽게 만들도록 함 -> set이 편리 *request는 요청 보내는 거 아님, 받은 요청을 읽는 것 따라서 content-type이나,인코딩 등등은 클라이언트가 요청 메시지 보내면서 잘 만들어서 보내야함 *서블릿은 톰캣 같은 서블릿을 지원하는 애플리케이션 서버를 직접 설치 -> 그 위에 서블릿 클래스 파일을 빌드해서 오린다음 -> 톰캣 서버를 실행함 (스프링 부트는 내장 톰캣 서버를 사용함) * ex war파일로 프로젝트를 export하고, 외장 톰캣 서버 webapp폴더에 이를 집어넣고,cmd..

1. 버블정렬 // int[] arr를 정렬한다고 가정 for(int i=0; i 0 ){ arr[dataIdx] = arr[getParent(dataIdx)]; dataIdx = getParent(dataIdx); }else break; } arr[dataIdx] = data; num++; } public int delete(){ int Dedata = arr[1]; int lastData = arr[num]; int DataIdx = 1; int child; while(true){ child = getHipriorityChildIdx(DataIdx); if(child == 0 && com.compare(lastData,arr[child]) >= 0) break; arr[DataIdx] = arr[ch..

1. 상태코드 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능 - 클라이언트가 인식할 수 없는 상태코드를 서버에서 반환하면? -> 클라이언트는 상위 상태코드로 해석해서 처리한다. -> 새로운 상태코드가 추가되어도 클라이언트를 변경하지 않아도 된다. 2. 2XX 성공 - 클라이언트 요청을 성공적으로 처리 - 200OK, - 201 Created : 새로운 리소스가 생성됨 (생성된 리소스는 응답 Location 헤더 필드로 식별) - 202 Accepted : 요청이 접수되었으나 처리가 완료되지 않음 (배치 처리 같은 곳에서 사용) - 204 No Content : 서버가 요청을 성공적으로 수행 but 응답 페이로드 본문에 보낼 데이터 없음 ex) 웹 문서 save버튼 3. 3XX 리다이렉션 -..

1. HTTP 메서드 활용 - 클라이언트에서 서버로 데이터 전송 - HTTP API 설계 예시 - 클라이언트에서 서버로 데이터를 전송하는 방식은 크게 2가지 이다. > GET (쿼리파라미터) VS POST,PUT,PATCH (바디를 통한 전송) 2. 클라이언트에서 서버로 데이터 전송 - 정적 데이터조회 : 이미지, 정적 텍스트 - 동적 데이터 : 주로 검색, 게시판 목록 정렬 필터 - HTML Form을 통한 데이터 전송 (회원가입,상품주문,데이터변경) - HTTP API를 통한 데이터 전송 (Form과 동일함 주로 서버 to 서버에서 사용) 2.1 정적 데이터 조회 (쿼리 파라미터 미사용) - 이미지,정적 텍스트, GET을 사용 - 정적 데이터는 일반적으로 쿼리 파라미터 없이 리소스 경로로 단순하게 조..

1. HTTP API - 요구사항 : 회원 정보 관리 > 회원 목록 조회 (/read-memebrList) > 회원 조회(/read-memebr-by-id) > 회원 등록(/create-member) > 회원 수정(/update-member) > 회원삭제 (/delete-member) - API설계에 가장 중요한 것은 리소스를 식별할 수 있어야한다는 것이다. 1.2 API URI 고민 - 리소스가 의미하는 것은 : 회원 등록, 수정등 행위가 아닌 회원 자체이다. - 리소스는 어떻게 식별하는 것이 좋은가: 행위는 배제 리소스를 URI에 매핑 > 회원 목록 조회 (/member) > 회원 조회(/member/{id}) > 회원 등록(/member/{id}) > 회원 수정(/member/{id}) > 회원삭제..

1. HTTP HyperText Transfer Protocol - HTML,TEXT,IMAGE,JSON등 여러 데이터를 전송하기 위한 규약임 (규약이라는 말은 요청과 응답에 특정 제약사항 및 특징이 있다는 것 -> 지켜야할 사항 ) - 기반 전송계층은 TCP와 UDP임 2. HTTP의 특징 2.1 클라이언트 서버 구조 - Request, Response구조 - 클라이언트는 서버에 요청을 보내고, 응답을 대기 - 서버가 요청에 대한 결과를 만들어 응답 2.2 무상태 프로토콜 - 서버는 클라이언트 상태를 보존하지않음 - 장점: 서버 확장성이 높다. - 단점: 클라이언트가 추가로 데이터를 전송해야함 - 모든 것을 무상태로 설계할 수 있는 경우도 있고 아닌 경우도 있음 - 무상태 (로그인 필요 없는 단순한 서..