복습을 위한

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

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

세가지의 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