복습을 위한

HTTP API를 어떤식으로 URI를 설계하는지 예시로 알아보자(바람직하게) 크게 POST기반 등록 PUT 기반 등록이 있다. 리소스를 식별하는 것은 '리소스'를 식별하는 것이 중요하다. 미네랄을 캐다에서 미네랄이 중요한 것이다. 수정같은 경우 고민을 좀 해봐야한다. PATCH는 부분적으로 수정할 수 있다. PUT은 아예 덮어버릴 때이다. 보통은 PATCH를 추천한다. PUT같은 경우 게시글 같은 것을 수정할 때 좋을 거다. 전부 다 갈기 때문이다. 애매할 때는 POST를 쓰자 POST의 자원 등록 특징은 서버가 새로 등록된 리소스 URI를 생성해준다. POST에 대해 포스팅을 할 때 설명했다. 서버에서 받은 유저정보를 데이터베이스에 저장하고 응답데이터로 새로 등록된 리소스 URI를 넘겨준다. 이런 형식..

클라이언트에서 서버로 데이터 전송 (데이터 전달 방식은 크게 2가지로 나눌 수 있다.) • 쿼리 파라미터를 통한 데이터 전송 • GET • 주로 정렬 필터(검색어) • 메시지 바디를 통한 데이터 전송 • POST, PUT, PATCH • 회원 가입, 상품 주문, 리소스 등록, 리소스 변경 클라이언트에서 서버로 데이터를 전송하는 상황은 네가지로 나뉜다. 먼저 정적데이터조회를 살펴보자 이미지나 정적 텍스트 문서가 해당된다. GET으로 URI경로를 보내면 서버에서 받아서 그 해당경로로 약속되어있는 리소스를 클라이언트에게 내려준다. 추가적인 쿼리데이터나 파라미터가 필요없다. • 이미지, 정적 텍스트 문서 • 조회는 GET 사용 • 정적 데이터는 일반적으로 쿼리 파라미터 없이 리소스 경로로 단순하게 조회 가능 다..

Linux 명령어를 이용해 시스템에서 동작 중인 process와 thread에 알아보자 참고 nhnacademy-bootcamp (github.com)

세가지의 HTTP 메서드의 속성이 있다. • 안전(Safe Methods) • 멱등(Idempotent Methods) • 캐시가능(Cacheable Methods) 각 속성은 메서드별로 그 여부가 다르다. GET은 리소스를 변경하지않지만 POST PUT DELETE PATCH를 리소스를 변경한다. POST는 멱등이 아니다. 배송을 두번? 결제를 두번? 클난다! 멱등이 왜 필요할까? 예를 들어 DELETE를 호출했는데 서버에서 응답이없다면 클라이언트가 자동으로 DELETE를 재시도하는 것이다. 자동복구메커니즘에 쓸 수 있다. 한가지 중요한 것은 멱등은 외부요인으로 중간에 리소스가 변경되는 것까지는 고려하지는않는다. 위와 같은 예시는 멱등하지않다고 판단하는 것이 맞다. 같은 요인일 때만 고려하는 것이다. ..

PUT은 리소스를 대체한다. 폴더에 파일을 복사하는 거랑 비슷하다보면된다. 기존에 똑같은 파일이 있다면 그것을 지우고 대체를 하는 것이다. post와 차이점이라면 리소스의 위치를 알고 uri를 지정한다. 리소스가 있는 경우는 리소스를 대체해버린다. 리소스가 없는 경우는 신규 리소스를 생성한다. 그런데 가장 중요한 점은 리소스를 완전히 대체한다는 것이다. PUT으로는 원하는 필드만을 대체할 수는 없는 것이다. 전부 대체가 되버리기 때문. 수정이 아니라 갈아치우는 것이다. 그렇다면 수정을 하고싶을때는 ??? 부분 변경을 하고싶을 때는 PATCH를 사용하자. 만약 PATCH를 지원안한다면 그럴 때는 POST를 사용하자 POST는 무적이니깐. DELETE는 말그대로 리소스를 제거하고 싶을 때 사용한다. 참고ht..

메서드는 클라이언트가 서버에게 뭔가 요청을 할 때 기대하는 행동이다. POST, PUT, PATCH는 메세지바디에 데이터를 담아서 서버로 보내야한다. 검색할 때 검색엔진에 필요한 파라미터를 넘길 때 query를 통해서 전달한다. 클라이언트가 100번 유저의 정보를 요청한다고 치자. 그러면 GET방식으로 정보를 보낸다. 그럼 서버는 그것을 받고 내부의 데이터베이스를 조회에 알맞은 정보를 JSON형태로 반환해준다.(다른 형태일 수도 있음) 서버에서 응답메세지를 만들어 클라이언트로 다시 보내주는 것이다. POST는 메시지 바디를 통해 서버로 요청 데이터를 전달한다. 클라이언트가 필요한 데이터를 보내면 서버는 미리 약속되어있는(예: /members로 요청이 오면 저장을 하는 로직을 미리구현)기능을 수행한다. 서..

좋은 URI설계는 무엇일까? 가장 중요한 것은 리소스 식별이다. 중요한 것은 '회원' 리소스라는 기준으로 설계하는 것이다. 조회 등록 수정 삭제등등 리소스가 아니다. 회원이라는 리소스만 식별하면 되므로 회원 리소스를 URI에 매핑을 하면된다. 근데 그럼 아래와 같은 문제가 발생한다. URI는 리소스를 판별하는데 쓰여야한다. 리소스의 행위를 판별하는데 쓰이는 것이 아니다. 그렇다면 조회, 등록, 삭제, 변경 등 행위(메소드)는 어떻게 구분을 할 것인가? 이럴 때 필요한 것이 바로 HTTP메소드이다. 메소드로 행위를 구분하는 것이다. 참고https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC/dashboard

본격적으로 http메세지에 대해 알아보자 시작라인 헤더, 공백라인, 메세지바디로 구성된다. 요청메세지도 body본문을 가질 수 있다. 먼저 시작라인을 살펴보 요청메세지의 시작라인은 시작라인은 request-line이다. http메소드, 요청대상, http버전으로 이루어진다. HTTP 메서드 • 종류: GET, POST, PUT, DELETE... • 서버가 수행해야 할 동작 지정 • GET: 리소스 조회 -->서버한테 리소스 요구! • POST: 요청 내역 처리-->내가 데이터 보내줄테니 처리해줘! 요청 메시지 - 요청 대상 • absolute-path[?query] (절대경로[?쿼리]) • 절대경로= "/" 로 시작하는 경로 • 참고: *, http://...?x=y 와 같이 다른 유형의 경로지정 방법..

먼저 연결을 유지하는 모델을 보자 여러 클라이언트와 서버가 연결되어있을 때 다른 클라이언트들이 놀고있을 때도 서버는 연결을 유지한다. 불필요한 서버자원이 소모 되는 것이다. 클라이언트 수만대라고 해보자. 막대한 자원이 소모될 것이다. 반대로 비연결성을 살펴보자 자원을 현재 요청을 주고받을 때만 연결을 하고 이후에 끊어버린다. 서버가 유지하는 자원을 최소화할 수가 있다. 하지만 새로연결하는 만큼 3way handshake 시간이 추가된다. 사용자입장에서는 불편할수도. 그것을 http지속연결(Persistent Connections)로 문제 해결을 한다. 최대한 무상태로 설계!!! 참고https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%..

Http특징 중 무상태 프로토콜을 알아보자 예시 상태유지(stateful) 클라이언트: 이 노트북 얼마인가요? 서버1: 100만원입니다 (노트북 상태 유지) 클라이언트: 2개 구매할게요 서버1: 200만 원입니다. 신용카드, 현금 중에 뭐로 계산하시겠어요? (노트북, 2개 상태 유지) 클라이언트: 신용카드요 서버1: 200만 원 결제되었습니다. (노트북, 2개, 신용카드 상태 유지) 위와 같이 클라이언트가 이전에 말한 것을 서버에게 다시 말하지 않는 것(서버가 클라이언트의 상태를 저장)을 stateful, 상태 유지라고 한다. 이때 근데 중간에 서버가 바뀌면 문제가 발생한다. 클라이언트: 노트북 얼마죠? 서버1: 100만 원입니다. 클라이언트: 2개 구매할게요 서버2: ?? 무엇을 2개 사신다는 거예요?..