티스토리 뷰

query param ==  query string (e.g. user?id=23)

path param == path parameter (e.g. user/23 )

*용어를 섞어 쓰지만 위와 같은 의미로 해석하시면 됩니다. 

 

day에 해당하는 day word list를 삭제하는 것은 다른 툴을 추가하지 않고 순수 react로는 작업이 번잡해진다. word 컴포넌트에서 props를 받아 렌더링하고 있으므로 부모 컴포넌트인 Day에서 word의 상태가 변화됨을 감지하고 변화된 내용을 감지하려면 word의 deleteWord 함수를 역으로 올려줘야 할 거 같음 react-query를 통해 서버 데이터의 변화가 일어났을 때, 클라이언트의 state값을 변경시켜주는 게 베스트 방법일 듯

 

특히, wordList는 day를 수정하는 페이지에서 표시되지않은(렌더링되지않은) 요소이기 때문에 이에 대해서 찾아봐야 했다.  올라가지 않은 컴포넌트의 데이터를 수정했을 때(http delete로 요청) 해당 값의 변경을 감지하여 다시 리렌더시키는 것은 클라이언트 상태관리툴과 서버사이드 상태관리툴이 없으면 실현하기 번거로움, 애초에 리액트에서 unmount된 컴포넌트의 state를 변경하는 것은 리액트의 기본이념과 맞지 않음, 브라우저 개발자도구의 warning을 보고 힌트를 얻었음, 서버데이터가 변했을때 리패칭하는 동작은 react-query를 통해 가능함

 

외에도 http delete 요청이 cors 404 에러를 낸 것에 대해서 좀 찾아봤다. 

fetch 에서 잘못된 endpoint로 요청을 보냈을 때에는 false와 404값을 가진다고 한다.  해당 url을 URL에 넣었을 때에는 제대로 내가 날리고자 하는 json 데이터가 보였는데 막상 fetch로 DELETE요청을 보냈을 때에는 404에러가 발생했다.

이에 대해 원인 가정을 해봤는데

  1. http DELETE 메서드는 컬럼 자체를 날려버릴 수 없다.
  2. url을 쿼리스트링으로 요청할 때에는 GET요청만 응답하고 DELETE 요청 시에는 다르게 동작한다?
  3. json-server 자체에서 DELETE 메서드를 막아버린 것 or 지원하지 않는 것이다.(복구가 어렵기 때문에 자체적으로 막은 것은 아닐 지) -> 그래서 POST요청으로도 해봤는데 똑같이 404에러를 반환했다.
  4. endpoint가 잘못 입력된 것이다. (10번 확인한듯..)
  5. 리액트에서 fetch로 조작하고자 하는 값이 화면상에 렌더링되지 않은 언마운트 컴포넌트 데이터라서 자체적으로 막은 것이다. -> day는 화면 상에서 첫렌더링 시 day.length 로 표시되어 있지만 해당 day에 해당하는 Word component는 화면상에 그려져 있지 않았다. 왜냐하면 해당 page는 day를 추가 삭제하는 기능을 담은 day조작 페이지이기 때문임

찾아본 바로는 http delete 요청은 요소 데이터 하나만 삭제 가능한 것 뿐만아니라 column(즉, 객체를 담은 리스트 자체)를 날려버릴 수 있으나 복구가 어렵기 때문에 권고되지 않음..?(결국 DELETE 메소드 자체는 문제가 없는 것)

 

리액트에서 언마운트된 데이터의 값을 변경하려고 fetch요청(DELETE)를 보내면 막는 것일까봐, postman으로 테스트를 해봤다.

postman으로 api 요청을 보냈을 때, json-server 에 query string으로 요청을 보내면 endpoint를 제대로 인식하지 못하는 것인지 서버자체에서 막는 것인지 query string으로 요청할 때에는 delete요청이 들어가지 않음 하지만 path parameter (e.g  example/2) 이런 식으로 DELETE 요청을 보냈을 때에는 정상 구동했다.

결론적으로 json-server에 query string으로 DELETE 요청을 보냈을 때 오류가 있는 거 같은데 정확한 지는 모르겠다.  

 

가설에 대한 정리

  1. 컬럼 자체를 날릴 수는 있는 거 같다
  2. 쿼리스트링은 보안상 문제이지 쿼리스트링과 파라미터의 동작 차이는 잘 모르겠음
  3. json-server 자체에서 DELETE 요청을 "쿼리스트링(a.k.a쿼리파람)으로" 할 때 문제같다 ✔ (path 파라미터로 하면 정상작동)
  4. endpoint는 제대로 입력했음
  5. 해당 페이지에서도 day.length 정보만 표시될 뿐, Day 컴포넌트와 Word 컴포넌트 둘 다 언마운트 상태이다. Warning을 표시할 뿐 요청 자체를 리액트에서 막는 것은 아닌 거 같다.

+https://stackoverflow.com/questions/4045484/http-delete-with-rest

 

http delete with REST

I am currently using Jersey Framework (JAX-RS implementation) for building RESTful Web Services. The Resource classes in the project have implemented the standard HTTP operations - GET,POST & D...

stackoverflow.com

pathParam(e.g. user/23) vs QueryParam(e.g. user?id=23)

-> 결론적으로 DELETE는 GET으로 요청되어 반환되는 애들만 삭제될 수 있음, 쿼리 파람이랑 패스 파람 둘 다 어느 측변에서는 가능하지만 pathParam을 사용하는 것이 권장되는 거 같다. 

  • local host 3001 번에서 json-server를 켜두고 내가 삭제하고자 하는 json형식의 데이터들을 get요청으로 확인했을 때는 값을 제대로 확인할 수 있었다. 근데 delete 요청 시에는 404 에러가 뜸..^ ^ why.. 

참고 자료 :

https://ryan-han.com/post/translated/pathvariable_queryparam/

 

[번역] Path Variable과 Query Parameter는 언제 사용해야 할까? | Integerous DevLog

[번역] Path Variable과 Query Parameter는 언제 사용해야 할까? 2019/04/23 원작자의 허락을 받고 번역한 글입니다. 원문: When Should You Use Path Variable and Query Parameter? *역자 주: Spring boot와 Vue.js로 파일럿 프로

ryan-han.com

 

댓글