복습을 위한

400번대와 500번대의 차이는 오류의 원인이다. 400번대는 오류의 원인이 클라이언트에게 있어서 클라이언트쪽에서 요청을 수정을 해야한다.(요청스펙을 잘못맞췄거나 인증이 안됨) 서버에서는 처리할 수가 없다. 백엔드개발는 사전에 미리 차단해서 400오류로 바로 튕겨내야한다. 철저하게 클라이언트 잘못이라고 명확하게 보내줘야한다. 그래야 클라이언트쪽에서 오류를 살펴볼 수 있으니말이다. 403은 인증은 됐지만 인가가 불가할 때 발생하는 오류코드이다. 자주보는코드이다. 서버입장에서는 이런 리소스가없는데 클라이언트에서 요청했을 때 발생한다. 또는 클라이언트가 권한이 부족한 리소스에 접근할 경우 해당 리소스를 숨기고 싶을 때도 404로 처리할 수 있다. 서버 내부 문제는 대부분 500오류를 쓴다. 백엔드에서 발생한 ..

영구리다이렉션과 다르게 검색엔진에서 url을 변경하면안된다. 다음에 어떻게 될 지 모르기 때문이다. 302 303은 비슷한데 실무에선302를 사용한다. 별 문제는 없다. PRG패턴을 알아보자. 상품을 주문하고 주문하기 버튼을 누른다고 하자. 그럼 post메서드로 서버로 내 데이터가 넘어갈 것이다. 자 그런상태에서 결과가 남아있다. 거기서 웹브라우져를 새로고침하면 어떻게 될까? post데이터가 한번 더 들어가서 서버에 중복주문이 들어갈 수도 있다. 요청했던 것을 새로고침해서 새로고침도 post요청이 또 되버리는 것이다, 이것을 해결해야한다.! PRG 사용 전부터 보자. 주문데이터가 요청이 와서 딱 저장이 됐다. 근데 클라이언트에서의 마지막 요청이 무엇이었나? 주문이었다. 실수로 새로고침누르면 마지막 요청을..

여기서 유저 에이전트는 웹브라우져를 말한다. 서버가 '너의 요청을 완료하려면 추가적인 작업이 필요해' 하고 전달하는 코드이다. 리다이렉션 이해 • 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동(리다이렉트) 원래 페이지에서 url이 바뀌었다고 하자. 하지만 원래 사용자들은 원래 url을 치고 들어갈 경우가 많을 것이다. 서버입장에선 그럼 어? 이제 안쓰는 건데 하고 클라이언트의 웹브라우져에게 알려준다. 그럼 웹브라우져가 어300대 코드고 location헤더 필드가 있네? 하고 스스로 url을 바꾸고 새로운 경로로 다시 요청을 한다. 서버가 그리고 다시 200번대 코드를 응답하는 것이다. 리다이렉션의 종류에는 크게 3가지가 있다. 방금 예시를 든 영구 ..

만약 낯선 상태코드를 서버가 반환한다면???????? 그냥 이렇게 이해하자. 상위상태코드로 해석해서 이해하자. 1xx번대(요청이 처리되어 수신중)는 거의 사용하지않는다. 2xx - 성공 차례대로 알아보자 가장 많이 보는 케이스이다. 200ok post요청은 서버에서 리소스를 생성하고 url관리도 서버가 한다는 것을 기억할 것이다. 200번대이므로 요청이 성공한 것은 이미 알거고 그 중 201이니깐 자원이생성됐고 location헤더가 있겠구나를 판단할 수 있다. 202는 잘 사용하진않는다. 204는 웹문서를 편집하다 save버튼을 누를 때를 생각하면 이해하기가 쉽다. 저장버튼을 누른다고 뭘 할 수 있는게 아니다. 우리는 계속 이어서 편집을 할 것이다. 결과내용없어도 메시지를 보고 성공을 인식할 수 있다. ..