잡다한 포스트

오늘은 HTTP 상태코드의 300번대에 대해 알아보겠다. 보통은 리다이렉션을 요청하는 상태코드이다. 300 번대 결과값이 나오는 요청에는 PRG가 있다. ( PRG란 Post/Redirect/Get 의 앞자리만 따온 것) PRG를 사용해야하는 예시를 하나 들어설명해보겠다. 만약 POST로 주문 후에 웹 브라우저를 새로 고침한다고 생각해보자. 새로고침은 다시 요청을 보내고, 중복주문이 될 수 있다. 이 상황을 단계로 나타내보자. 1단계 : 주문을 클라이언트에서 요청한다. (POST) 2단계 : 서버는 주문데이터를 디비에 저장한다. 3단계 : 디비에 저장후 서버는 클라이언트에 성공 메시지를 응답한다. 4단계 : 결과 화면에서 새로고침을 한다.(POST) 5단계 : 또 다시 요청이 클라이언트에서 서버로 들어간..

HTTP API는 예시를 POST기반과 PUT 기반으로 나누어 들수 있다. POST 기반 API 설계 예시 회원 목록 /members -> GET 회원 등록 /members -> POST 회원 조회 /members/{id} -> GET 회원 수정 /members/{id} -> PATCH, PUT, POST 회원 삭제 /members/{id} -> DELETE 여기서 URL(members)은 동사가 아닌 자원 그 자체로 설정해야 한다. 위 예씨를 보면 목록과 등록이 같은 URL인데 이것은 GET과 POST의 차이이다. 단순한 조회의 경우에는 GET을 사용하고 데이터를 등록하거나 수정하는 것 등의 경우에는 PATCH, PUT, POST를 적절히 사용하면 된다. 다음은 PUT 기반의 API 설계 예시이다. 파..

1. 주요 메서드 - GET : 리소스 조회 - POST : 요청 데이터 처리, 주로 등록에 사용 - PUT : 리소스를 대체, 해당 리소스가 없으면 생성 - PATCH : 리소스 부분 변경 - DELETE : 리소스 삭제 1.2 기타 메서드 - HEAD : GET과 동일하지만 메시지 부분을 제외하고, 상태 줄과 헤더만 반환 - OPTIONS : 대상 리소스에 대한 통신 가능 옵션(메서드)을 설명(주로 CORS에서 사용) - CONNECT : 대상 자원으로 식별되는 서버에 대한 터널을 설정 (주로 사용 X) - TRACE : 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행 (주로 사용 X) 2. GET - 리소스 조회 - 서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)..