데이터 전달 방식 쿼리 파라미터를 통한 데이터 전송 GET 주로 정렬 필터 (검색어) 메시지 바디를 통한 데이터 전송 POST, PUT, PATCH 회원가입, 상품 주문, 리소스 등록, 리소스 변경 4가지 상황 정적 데이터 조회 (GET) 이미지, 정적 텍스트 문서 쿼리 파라미터 없이 리소스 경로로 단순하게 조회 가능 동적 데이터 조회 (GET) 주로 검색, 게시판 목록에서 정렬 필터 (검색어) 조회 조건을 줄여주는 필터, 조회 결과를 정렬하는 정렬 조건에 주로 사용 GET은 쿼리 파라미터를 사용해서 데이터를 전달 HTML Form을 통한 데이터 전송 회원 가입, 상품 주문, 데이터 변경 POST-저장 HTML form 태그 Content-Type : application/x-www-form-urlenc..
안전 (Safe Methods) 호출해도 리소스를 변경하지 않는다. 안전한 메소드 = GET, HEAD, OPTIONS, TRACE 안전하지 않은 메소드 = POST, PUT, DELETE, CONNECT, PATCH 멱등 (Idempotent Methods) f(f(x)) = f(x) 1번 호출하든, 2번 호출하든, 100번 호출하든 결과가 똑같다. 멱등 메서드 GET : 1번 조회하든, 2번 조회하든 같은 결과가 조회된다. PUT : 결과를 대체한다. 같은 요청을 여러번 해도 최종 결과는 같다. DELETE : 결과를 삭제한다. 같은 요청을 여러번 해도 삭제된 결과는 같다. POST = 멱등이 아니다! 2번 호출하면 같은 결제가 중복해서 발생할 수 있다. 활용 자동 복구 메커니즘 서버가 TIMEOUT..
HTTP API를 만들어보자 요구사항 회원 정보 관리 API를 만들어라 조회 회원 목록 조회 회원 조회 등록 회원 등록 수정 회원 수정 삭제 회원 삭제 API URI 설계 Uniformed Resource Indentifier 회원 목록 조회 (read-member-list) 회원 조회 (read-member-by-id) 회원 등록 (create-member) 회원 수정 (update-member) 회원 삭제 (delete-member) 가장 중요한 것은 리소스 식별 리소스의 의미 회원을 등록하고 수정하고 조회하는게 리소스가 아니다. 회원이라는 개념 자체가 리소스다. 리소스를 어떻게 식별하는게 좋을까? 회원이라는 리소스만 식별하면 된다. 회원 리소스를 URI에 매핑 리소스 식별, URI 계층 구조 활용 ..
HTTP 메시지 구조 start-line : 시작 라인 header : 헤더 empty line (CRLF) : 공백 라인 message body HTTP 요청 메시지 start-line GET /search?q=hello&hl=ko HTTP/1.1 header Host: www.google.com 요청 메시지도 body 본문을 가질 수 있음 HTTP 응답 메시지 start-line HTTP/1.1 200 OK header Content-Type: text/html;charset=UTF-8 Content-Length: 3423 CRLF message body ... Start Line 요청 메시지 start-line = request-line request-line = method SP(공백) reque..
HTTP ( HyperText Transfer Protocol) 거의 모든 형태 데이터를 HTTP 메시지에 담아서 전송한다. HTML, TEXT IMAGE, 음성, 영상, 파일 JSON, XML (API) 서버간에 데이터를 주고 받을 때도 대부분 HTTP 사용 HTTP 역사 HTTP/0.9 : GET 메서드만 지원, HTTP 헤더 없음 HTTP/1.0 : 메서드, 헤더 추가 HTTP/1.1 : 가장 많이 사용 RFC2068(1997) -> RFC2616(1999) -> RFC7230~7235(2014) HTTP/2 : 성능 개선 HTTP/3 : TCP 대신에 UDP 사용, 성능 개선 기반 프로토콜 TCP : HTTP/1.1. HTTP/2 UDP : HTTP/3 느린 TCP 대신 UDP 프로토콜 위에 애플..
DNS 조회 www.google.com:443 ip : 200.200.200.2 HTTP 요청 메시지 생성 HTTP 요청 메시지 웹 브라우저가 HTTP 메시지 생성 SOCKET 라이브러리를 통해 전달 A : TCP/IP 연결 (IP, PORT) B : 데이터 전달 TCP/IP 패킷 생성, HTTP 메시지 포함 패킷 생성 TCP/IP 패킷 출발지 IP, PORT 목적지 IP, PORT HTTP 메시지 search : 검색 query parameter HTTP 응답 메시지
URI : Uniform Resource Identifier Uniform : 리소스를 식별하는 통일된 방식 Resource : 자원, URI로 식별할 수 있는 모든 것 (제한 없음) Identifier : 다른 항목과 구분하는데 필요한 정보 URL (Locator) : 리소스가 있는 위치를 지정 URN (Name) : 리소스에 이름을 부여 URN 이름만으로 실제 리소스를 찾을 수 있는 방법이 보편화 되지 않음. URI는 locator, name 또는 둘 다 추가로 분류될 수 있다. URL : Resource Locator 리소스의 위치 URN : Resource Name 리소스의 이름 URL (전체 문법) Scheme://[userinfo@]host[:port][/path][?query][#fragme..
DI(의존관계 주입) : 객체가 의존하는 또 다른 객체를 외부에서 선언하고 이를 주입받아 사용하는 것이다. 클래스 모델이나 코드에는 런타임 시점의 의존관계가 드러나지 않는다. 그러기 위해서는 인터페이스만 의존하고 있어야 한다. 런타임 시점의 의존관계에는 컨테이너나 팩토리 같은 제 3의 존재가 결정한다. 의존관계는 사용할 오브젝트에 대한 레퍼런스를 외부에서 주입해줌으로써 만들어진다 DI 구현방법 기존 코드 class BurgerChef{ private BurgerRecipe burgerRecipe; public BurgerChef(){ burgerReceipe = new HamBurgerReceipe(); } } 생성자를 이용 class BurgerChef{ private BurgerRecipe burge..
공식 문서 : https://junit.org/junit5/docs/current/api/org.junit.jupiter.api/org/junit/jupiter/api/Assertions.html Assertions (JUnit 5.9.1 API) Assert that all supplied executables do not throw exceptions. If any supplied Executable throws an exception (i.e., a Throwable or any subclass thereof), all remaining executables will still be executed, and all exceptions will be aggregated and reported i ju..
공식문서 : https://joel-costigliola.github.io/assertj/assertj-core-features-highlight.html AssertJ / Fluent assertions for java AssertJ has many great features that not everybody is aware of, here are some of them. Basic tips : Iterable and arrays assertions : Advanced tips : We want to start typing asser and let code completion suggest assertThat from AssertJ (and not the one from joel-costigliola...
