Jay

HTTP API 설계 예시를 살펴보자. HTTP API - 컬렉션 POST 기반 등록 예) 회원 관리 API 제공 HTTP API - 스토어 PUT 기반 등록 예) 정적 컨텐츠 관리, 원격 파일 관리 HTML FORM 사용 웹 페이지 회원 관리 GET, POST만 지원 회원 관리 시스템을 만든다고 하자. / members는 collections라고 한다. 회원 목록 / members => GET 회원 등록 / members => POST 회원 조회 / members/{id} -> GET 회원 수정 / members/{id} -> PATCH, PUT, POST 회원 삭제 / members/{id} -> DELETE POST -신규 자원 등록 특징 클라이언트는 등록될 리소스의 URI를 모른다. 회원 등록 /..

클라이언트에서 서버로 데이터 전송 HTTP API 설계 예시 데이터 전달 방식은 크게 2가지가 있는데 쿼리 파라미터를 통한 데이터 전송 GET 주로 정렬 필터(검색어) 메시지 바디를 통한 데이터 전송 POST, PUT, PATCH 회원 가입, 상품 주문, 리소스 등록, 리소스 변경 4가지 상황을 보자. 정적 데이터 조회 이미지, 정적 텍스트 문서 동적 데이터 조회 주로 검색, 게시판 목록에서 정렬 필터(검색어) HTML Form을 통한 데이터 전송 회원 가입, 상품 주문, 데이터 변경 HTTP API를 통한 데이터 전송 회원 가입, 상품 주문, 데이터 변경 서버 to 서버, 앱 클라이언트, 웹 클라이언트(Ajax) 정적 데이터 조회 쿼리 파라미터 미사용 이미지 리소스를 만들어서 클라이언트에게 내려준다. ..

안전(Safe Methods) 멱등(Idempotent Methods) 캐시가능(Cacheable Methods) 안전(Safe) Safe 호출해도 리소스를 변경하지 않는다. 계속 호출을 하여서 로그 같은게 쌓여서 장애가 발생하면? 안전은 해당 리소스만 고려 / 그러한 부분까지 고려 안한다. 멱등(Idempotent) f(f(x)) = f(x) 한 번 호출하든 두 번 호출하든 100 번을 호출하든 결과가 같다. 멱등 메서드 GET: 한 번 조회를 하든, 두 번 조회하든 같은 결과가 조회된다. PUT: 결과를 대체하는데 같은 요청을 여러번 해도 최종 결과는 같다. DELETE: 결과를 삭제하는데 같은 요청을 여러번 해도 삭제된 결과는 같다. POST: 이 아이는 멱등이 아니다. 두 번 호출하면 같은 결제가..

PUT 리소스를 대체 리소스가 있으면 대체 리소스가 없으면 생성 쉽게 이야기해서 덮어버린다. 중요! 클라이언트가 리소스를 식별 클라이언트가 리소스 위치를 알고 URI 지정 POST와 차이점 PUT으로 리소스를 날리는 경우 날린 데이터로 기존의 데이터를 대체한다. 리소스가 없는 경우에는 신규 리소스를 생성한다. 즉 리소스를 완전히 대체한다. 전달할 데이터에 username 필드가 없다? 그러면 username 필드가 삭제된다. PATCH를 써보자. 부분적으로 age라는 리소스의 데이터를 변경하고 싶다. 가능하다! 만약 PATCH를 지원안하는 서버가 있을 수도 있다. (HTTP 자체에서 PATCH를 못 받아들이는 경우인데 그럴 때는 POST를 쓰자. POST는 무적이다.) DELETE는 말그대로 DELETE..

HTTP 메서드 종류를 알아보자. 주요 메서드 GET: 리소스 조회 POST: 요청 데이터 처리, 주로 등록에 사용 PUT: 리소스를 대체, 해당 리소스가 없으면 생성 PATCH: 리소스 부분 변경 DELETE: 리소스 삭제 기타 메서드 HEAD: GET과 동일하지만 메시지 부분을 제외하고, 상태 줄과 헤더만 반환 OPTIONS: 대상 리소스에 대한 통신 가능 옵션(메서드)을 설명(주로 CORS에서 사용) CONNECT: 대상 자원으로 식별되는 서버에 대한 터널을 설정 TRACE: 대상 리소스에 대한 경로를 따라서 메시지 루프백 테스트를 수행 GET 리소스 조회 서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)을 통해서 전달. 메시지 바디를 사용해서 데이터 전달 가능하지만, 지원하지..

API 설계를 해보자. 회원 목록 조회 회원 조회 회원 등록 회원 수정 회원 삭제 아래의 좋지 않은 설계를 보자. 회원 목록 조회 / read-member-list 회원 조회 / read-member-by-id 회원 등록 / creadte-member 회원 수정 / update-member 회원 삭제 / delete-member 가장 중요한 것은 리소스 식별이다. API URI 고민 리소스의 의미는? 회원을 등록하고 수정하고 조회하는게 리소스는 아님 회원이라는 개념 자체가 바로 리소스 리소스를 어떻게 식별할까 회원을 등록하고 수정하고 조회하는 것을 모두 배제 회원이라는 리소스만 식별하자. 회원 리소스를 URI에 매핑 리소스 식별, URI 계층 구조 활용(URI 설계는 리소스 식별 + URI 계층 구조로 ..

velog1 백엔드 면접 질문 따라써보기 TIL(3) 원본 사이트를 보며 만들었고 질문을 하나하나 적어보는 것과 나중에 채워가는 것이 도움이 되리라 생각하고 적습니다. Information 백엔드 개발자를 준비하면서 받았던 면접 질문, 학습했던 내용, velog.io velog2 JSP, Servlet 본격적인 방대한 BE 판타지 세계를 다루기 이전에 앞서 이전 포스팅에서 세계관(웹 구조)에 대해 인트로를 시작했습니다. 그렇다면 이번에는 험험 시간 순서대로, 그러니까... 지금부터 옛날옛날 velog.io velog3 JPA는 도대체 뭘까? (orm, 영속성, hibernate, spring-data-jpa) JPA는 도대체 무엇일까요? orm, jdbc, 영속성, hibernate, ... 관련 지식까..

직접 만든 MVC 프레임워크 개발해 나갈 SpringMVC 구조는 이렇다. 위와 완전 비슷하다. 직접 만든 프레임워크 스프링 MVC 비교를 해보면 FrontController =>DispatcherServlet handlerMappingMap => HandlerMapping MyHandlerAdapter => HandlerAdapter ModelView => ModelAndView viewResolver => ViewResolver MyView => View로 되어있다. DispatcherServlet 구조를 보면 org.springframework.web.servlet.DispatcherServlet 스프링 MVC도 프론트 컨트롤러 패턴으로 구현되어 있다. 동작 순서 핸들러 조회: 핸들러 매핑을 통해 ..

이번에는 v4를 한번 넣어보자. private void initHandlerMappingMap() { handlerMappingMap.put("/front-controller/v5/v3/members/new-form", new MemberFormControllerV3()); handlerMappingMap.put("/front-controller/v5/v3/members/save", new MemberSaveControllerV3()); handlerMappingMap.put("/front-controller/v5/v3/members", new MemberListControllerV3()); //V4 추가 handlerMappingMap.put("/front-controller/v5/v4/members/..

이제 어댑터 패턴을 써보자 V3 V4에서 개발한 프론트 컨트롤러는 한가지 방식의 컨트롤러 인터페이스만 계속해서 사용했다. `ControllerV3`, `ControllerV4`는 완전히 다른 인터페이스이고 호환이 불가능하다. 어댑터 패턴을 사용해서 프론트 컨트롤러가 다양한 방식의 컨트롤러를 처리하도록 변경하자. V5 구조를 만들어서 보자. 중간에 핸들러 어댑터를 두자. 그러면 FrontController가 직접 Controller를 호출하는 것이 아니고 어댑터를 통해서 호출을 한다. FrontController가 어댑터한테 handler 파라미터를 넘겨서 어댑터가 컨트롤러한테 다른 걸 호출해준다. 그러면 핸들러 어댑터가 대신 호출해주고 핸들러한테 결과 받고 FrontController한테 ModelVi..