<div id="readability-page-1" class="page"><div id="dkContent" role="main">

					

					
						<h2>강디너의 개발 일지</h2>
					

					 
 
	


	
		
		
		<div><figure data-ke-mobilestyle="widthOrigin" data-origin-width="750" data-origin-height="600"><img src="https://blog.kakaocdn.net/dn/bnxwPk/btsfg3HVgcI/Ffv8ElvU2ZidZMoECZi7O0/img.jpg" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" width="650" height="520" data-origin-width="750" data-origin-height="600"><figcaption>https://http.cat</figcaption>
</figure>


HTTP 상태 코드는 웹 서버와 클라이언트 간의 통신 과정에서 클라이언트 요청에 대한 서버의 응답 결과를 전달하는 코드입니다. 이 코드는 HTTP 응답의 일부로 사용되며, 성공, 클라이언트 오류, 서버 오류 등의 여러 상황을 나타낼 수 있습니다.

프론트엔드 팀과 백엔드 팀이 HTTP 상태 코드를 기준으로 특정 상황에 대한 코드 값을 약속하게 된다면 불필요한 커뮤니케이션을 줄일 수 있습니다.

예를 들어 HTTP 상태 코드가 401인 경우 로그인이 필요한 상태라고 약속합니다.
백엔드에서는 인증이 필요한 사용자일 경우 401로 내려주고, 프론트엔드에서는 401 코드만 딱 잡아서 로그인이 필요하다고 사용자에게 보여주거나, 로그인 페이지로 이동시킬 수 있습니다.&nbsp;

백엔드에서 HTTP 상태 코드로 구분시키는 게 아닌 response 값으로도 구분가능하게 할 수 있지만, 이런 상황이 많아질수록 관리하기 힘들어질 것입니다. 그리고 백엔드 팀이 많을수록, 프론트엔드 팀이 많을 수록 다양한 조건들이 나올 수 있습니다. (a다르고 A가 다른데...) 예시를 먼저 보여드리겠습니다.

HTTP 상태 코드에 담겨있는 경우입니다.
<pre id="code_1684679293247" data-ke-language="javascript" data-ke-type="codeblock"><code>try {
 const data = await axios.get(‘/userInfo’);
 // API가 성공했기 때문에 유저 정보가 있을 것으로 예상
 console.log(data);
 return data;
} catch (err) {
 // 4xx 또는 5xx 일 경우 (실패할 경우) err에 나올 것으로 예상
 console.log(err);
 if (err.status === 401) {
 	alert('로그인이 필요합니다.');
 }
}</code></pre>

또는 axios interceptor에서 공통으로 처리할 수 있습니다.
이렇게 할 경우 try catch 문마다 if문을 달 필요가 없게 됩니다.
<pre id="code_1684679293250" data-ke-language="javascript" data-ke-type="codeblock"><code>// 응답 인터셉터 추가하기
axios.interceptors.response.use(function (response) {
 // 2xx 범위에 있는 상태 코드는 이 함수를 트리거 합니다.
 // 응답 데이터가 있는 작업 수행
 return response;
 }, function (error) {
 // 2xx 외의 범위에 있는 상태 코드는 이 함수를 트리거 합니다.
 
 if (error.response.status === 401) {
 	alert('로그인 필요 !!');
 }
 // 응답 오류가 있는 작업 수행
 return Promise.reject(error);
 });</code></pre>

하지만&nbsp;API가&nbsp;200&nbsp;성공했지만&nbsp;data에서&nbsp;실패한&nbsp;값을&nbsp;준다고&nbsp;가정하면 try catch문으로 핸들링할 수 없이 data에서&nbsp;에러를&nbsp;한번&nbsp;더&nbsp;찾아야 하는&nbsp;작업이&nbsp;필요합니다.
<pre id="code_1684679293252" data-ke-language="javascript" data-ke-type="codeblock"><code>try {
 const data = await axios.get(‘/userInfo’);
 // API가 성공했기 때문에 유저 정보가 있을 것으로 예상
 console.log(data);
 
 // 우린 오류를 data 안에 넣어줄꺼야 !
 if(data.code === 500 || data.code === 400) {
		throw(‘오류래요’)
	}
 return data;
} catch (err) {
 // 4xx 또는 5xx 일 경우 (실패할 경우) err에 나올 것으로 예상
 console.log(err);
}</code></pre>
GET userInfo 에 추가된 건 단 3줄이지만, API 통신코드가 많아질수록 중복코드가 늘어납니다.

이 부분도 axios interceptors를 이용해서 똑같이 적용할 순 있지만, 성공했을 때의 인터셉터를 하기 때문에 이 부분을 잘 모르는 팀원이 보면 의문을 가질 수 있습니다.

500, 400 뿐만 아니라 다양한 케이스가 발생할 것이기 때문에 관리가 잘 된다면 상관없지만
그것이&nbsp;아니라면….


여기부터는 이론적인 거!!

HTTP&nbsp;상태&nbsp;코드는&nbsp;3자리&nbsp;숫자로&nbsp;이루어져&nbsp;있으며,&nbsp;첫&nbsp;번째&nbsp;숫자는&nbsp;응답의&nbsp;성격을&nbsp;나타냅니다.&nbsp;
5개의 그룹
<ul data-ke-list-type="disc">
<li>정보를 제공하는 응답 (1xx)</li>
<li>성공 응답 (2xx)</li>
<li>리다이렉트 응답 (3xx)</li>
<li>클라이언트 에러 응답 (4xx)</li>
<li>서버 에러 응답 (5xx)</li>
</ul>

<a href="https://http.cat/" target="_blank" rel="noopener">https://http.cat/</a> 이라는 HTTP 코드에 대한 귀여운 사이트도 있습니다.
<figure id="og_1684080217035" contenteditable="false" data-ke-type="opengraph" data-ke-align="alignCenter" data-og-type="website" data-og-title="HTTP Cats" data-og-description="API for HTTP Cats" data-og-host="http.cat" data-og-source-url="https://http.cat/" data-og-url="https://http.cat" data-og-image="https://scrap.kakaocdn.net/dn/tqdKP/hySBzig7aV/K5mg95GNIvwgbmYI2TPBAK/img.jpg?width=750&amp;height=600&amp;face=0_0_750_600,https://scrap.kakaocdn.net/dn/WwV3I/hySBB8eUSm/hzKAB1qzLMVhKU9Y5EJFu1/img.jpg?width=750&amp;height=600&amp;face=0_0_750_600"><a href="https://http.cat/" target="_blank" rel="noopener" data-source-url="https://http.cat/">

<div>
HTTP Cats
API for HTTP Cats
http.cat
</div>
</a><img src="https://scrap.kakaocdn.net/dn/tqdKP/hySBzig7aV/K5mg95GNIvwgbmYI2TPBAK/img.jpg?width=750&amp;height=600&amp;face=0_0_750_600,https://scrap.kakaocdn.net/dn/WwV3I/hySBB8eUSm/hzKAB1qzLMVhKU9Y5EJFu1/img.jpg?width=750&amp;height=600&amp;face=0_0_750_600"></figure>
<hr contenteditable="false" data-ke-type="horizontalRule" data-ke-style="style2">
<a href="https://ko.wikipedia.org/wiki/HTTP_%EC%83%81%ED%83%9C_%EC%BD%94%EB%93%9C" target="_blank" rel="noopener">위키백과</a> 기준

1xx
<ul data-ke-list-type="disc">
<li>100(계속): 요청자는 요청을 계속해야 한다. 서버는 이 코드를 제공하여 요청의 첫 번째 부분을 받았으며 나머지를 기다리고 있음을 나타낸다.</li>
<li>101(프로토콜 전환): 요청자가 서버에 프로토콜 전환을 요청했으며 서버는 이를 승인하는 중이다.</li>
</ul>
2xx
<ul data-ke-list-type="disc">
<li>200(성공): 서버가 요청을 제대로 처리했다는 뜻이다. 이는 주로 서버가 요청한 페이지를 제공했다는 의미로 쓰인다.</li>
<li>201(작성됨): 성공적으로 요청되었으며 서버가 새 리소스를 작성했다.</li>
<li>202(허용됨): 서버가 요청을 접수했지만 아직 처리하지 않았다.</li>
<li>203(신뢰할 수 없는 정보): 서버가 요청을 성공적으로 처리했지만 다른 소스에서 수신된 정보를 제공하고 있다.</li>
<li>204(콘텐츠 없음): 서버가 요청을 성공적으로 처리했지만 콘텐츠를 제공하지 않는다.</li>
<li>205(콘텐츠 재설정): 서버가 요청을 성공적으로 처리했지만 콘텐츠를 표시하지 않는다. 204 응답과 달리 이 응답은 요청자가 문서 보기를 재설정할 것을 요구한다(예: 새 입력을 위한 양식 비우기).</li>
<li>206(일부 콘텐츠): 서버가 GET 요청의 일부만 성공적으로 처리했다.</li>
</ul>
3xx
<ul data-ke-list-type="disc">
<li>300(여러 선택항목): 서버가 요청에 따라 여러 조치를 선택할 수 있다. 서버가 사용자 에이전트에 따라 수행할 작업을 선택하거나, 요청자가 선택할 수 있는 작업 목록을 제공한다.</li>
<li>301(영구 이동): 요청한 페이지를 새 위치로 영구적으로 이동했다. GET 또는 HEAD 요청에 대한 응답으로 이 응답을 표시하면 요청자가 자동으로 새 위치로 전달된다.</li>
</ul>
4xx
<ul data-ke-list-type="disc">
<li>400(잘못된 요청): 서버가 요청의 구문을 인식하지 못했다.</li>
<li>401(권한 없음): 이 요청은 인증이 필요하다. 서버는 로그인이 필요한 페이지에 대해 이 요청을 제공할 수 있다. 상태 코드 이름이 권한 없음(Unauthorized)으로 되어 있지만 실제 뜻은 인증 안됨(Unauthenticated)에 더 가깝다.</li>
<li>402(결제&nbsp;필요):&nbsp;이&nbsp;요청은&nbsp;결제가&nbsp;필요합니다.</li>
<li>403(Forbidden,&nbsp;금지됨):&nbsp;서버가&nbsp;요청을&nbsp;거부하고&nbsp;있다.&nbsp;예를&nbsp;들자면,&nbsp;사용자가&nbsp;리소스에&nbsp;대한&nbsp;필요&nbsp;권한을&nbsp;갖고&nbsp;있지&nbsp;않다.&nbsp;(401은&nbsp;인증&nbsp;실패,&nbsp;403은&nbsp;인가&nbsp;실패라고&nbsp;볼&nbsp;수&nbsp;있음)</li>
<li>404(Not&nbsp;Found,&nbsp;찾을&nbsp;수&nbsp;없음):&nbsp;서버가&nbsp;요청한&nbsp;페이지(Resource)를&nbsp;찾을&nbsp;수&nbsp;없다.&nbsp;예를&nbsp;들어&nbsp;서버에&nbsp;존재하지&nbsp;않는&nbsp;페이지에&nbsp;대한&nbsp;요청이&nbsp;있을&nbsp;경우&nbsp;서버는&nbsp;이&nbsp;코드를&nbsp;제공한다.</li>
<li>405(허용되지&nbsp;않는&nbsp;메소드):&nbsp;요청에&nbsp;지정된&nbsp;방법을&nbsp;사용할&nbsp;수&nbsp;없다.&nbsp;예를&nbsp;들어&nbsp;POST&nbsp;방식으로&nbsp;요청을&nbsp;받는&nbsp;서버에&nbsp;GET&nbsp;요청을&nbsp;보내는&nbsp;경우,&nbsp;또는&nbsp;읽기&nbsp;전용&nbsp;리소스에&nbsp;PUT&nbsp;요청을&nbsp;보내는&nbsp;경우에&nbsp;이&nbsp;코드를&nbsp;제공한다.</li>
<li>406(허용되지&nbsp;않음):&nbsp;요청한&nbsp;페이지가&nbsp;요청한&nbsp;콘텐츠&nbsp;특성으로&nbsp;응답할&nbsp;수&nbsp;없다.</li>
</ul>
5xx
<ul data-ke-list-type="disc">
<li>500(내부 서버 오류): 서버에 오류가 발생하여 요청을 수행할 수 없다.</li>
<li>501(구현되지 않음): 서버에 요청을 수행할 수 있는 기능이 없다. 예를 들어 서버가 요청 메소드를 인식하지 못할 때 이 코드를 표시한다.</li>
<li>502 (Bad Gateway, 불량 게이트웨이): 서버가 게이트웨이나 프록시 역할을 하고 있거나 또는 업스트림 서버에서 잘못된 응답을 받았다.</li>
<li>503(서비스를 사용할 수 없음): 서버가 오버로드되었거나 유지관리를 위해 다운되었기 때문에 현재 서버를 사용할 수 없다. 이는 대개 일시적인 상태이다.</li>
<li>504(게이트웨이 시간초과): 서버가 게이트웨이나 프록시 역할을 하고 있거나 또는 업스트림 서버에서 제때 요청을 받지 못했다.</li>
</ul>
<hr contenteditable="false" data-ke-type="horizontalRule" data-ke-style="style2">



참고
<a href="https://developer.mozilla.org/ko/docs/Web/HTTP/Status" target="_blank" rel="noopener">https://developer.mozilla.org/ko/docs/Web/HTTP/Status</a>
<a href="https://axios-http.com/kr/docs/handling_errors" target="_blank" rel="noopener">https://axios-http.com/kr/docs/handling_errors</a>

</div>
	
		<img src="https://tistory1.daumcdn.net/tistory/2781910/skin/images/giveMe.png" alt="커피한잔...">
		
		

		
			
		

		


	

 
 

					

					

					

					

					

					
				</div></div>

강디너의 개발 일지

HTTP 상태 코드는 웹 서버와 클라이언트 간의 통신 과정에서 클라이언트 요청에 대한 서버의 응답 결과를 전달하는 코드입니다. 이 코드는 HTTP 응답의 일부로 사용되며, 성공, 클라이언트 오류, 서버 오류 등의 여러 상황을 나타낼 수 있습니다.
 
프론트엔드 팀과 백엔드 팀이 HTTP 상태 코드를 기준으로 특정 상황에 대한 코드 값을 약속하게 된다면 불필요한 커뮤니케이션을 줄일 수 있습니다.
 
예를 들어 HTTP 상태 코드가 401인 경우 로그인이 필요한 상태라고 약속합니다.
백엔드에서는 인증이 필요한 사용자일 경우 401로 내려주고, 프론트엔드에서는 401 코드만 딱 잡아서 로그인이 필요하다고 사용자에게 보여주거나, 로그인 페이지로 이동시킬 수 있습니다. 
 
백엔드에서 HTTP 상태 코드로 구분시키는 게 아닌 response 값으로도 구분가능하게 할 수 있지만, 이런 상황이 많아질수록 관리하기 힘들어질 것입니다. 그리고 백엔드 팀이 많을수록, 프론트엔드 팀이 많을 수록 다양한 조건들이 나올 수 있습니다. (a다르고 A가 다른데...) 예시를 먼저 보여드리겠습니다.
 
HTTP 상태 코드에 담겨있는 경우입니다.
try {
    const data = await  axios.get(‘/userInfo’);
    //  API가 성공했기 때문에 유저 정보가 있을 것으로 예상
    console.log(data);
    return data;
} catch (err) {
    // 4xx 또는 5xx 일 경우 (실패할 경우) err에 나올 것으로 예상
    console.log(err);
    if (err.status === 401) {
    	alert('로그인이 필요합니다.');
    }
}
 
또는 axios interceptor에서 공통으로 처리할 수 있습니다.
이렇게 할 경우 try catch 문마다 if문을 달 필요가 없게 됩니다.
// 응답 인터셉터 추가하기
axios.interceptors.response.use(function (response) {
    // 2xx 범위에 있는 상태 코드는 이 함수를 트리거 합니다.
    // 응답 데이터가 있는 작업 수행
    return response;
  }, function (error) {
    // 2xx 외의 범위에 있는 상태 코드는 이 함수를 트리거 합니다.
    
    if (error.response.status === 401) {
    	alert('로그인 필요 !!');
    }
    // 응답 오류가 있는 작업 수행
    return Promise.reject(error);
  });
 
하지만 API가 200 성공했지만 data에서 실패한 값을 준다고 가정하면
try catch문으로 핸들링할 수 없이 data에서 에러를 한번 더 찾아야 하는 작업이 필요합니다.
try {
    const data = await  axios.get(‘/userInfo’);
    //  API가 성공했기 때문에 유저 정보가 있을 것으로 예상
    console.log(data);
    
    // 우린 오류를 data 안에 넣어줄꺼야 !
    if(data.code === 500 || data.code === 400) {
		throw(‘오류래요’)
	}
    return data;
} catch (err) {
    // 4xx 또는 5xx 일 경우 (실패할 경우) err에 나올 것으로 예상
    console.log(err);
}
GET userInfo 에 추가된 건 단 3줄이지만, API 통신코드가 많아질수록 중복코드가 늘어납니다.
 
이 부분도 axios interceptors를 이용해서 똑같이 적용할 순 있지만, 성공했을 때의 인터셉터를 하기 때문에 이 부분을 잘 모르는 팀원이 보면 의문을 가질 수 있습니다.
 
500, 400 뿐만 아니라 다양한 케이스가 발생할 것이기 때문에 관리가 잘 된다면 상관없지만
그것이 아니라면….
 
 
여기부터는 이론적인 거!!
 
HTTP 상태 코드는 3자리 숫자로 이루어져 있으며, 첫 번째 숫자는 응답의 성격을 나타냅니다. 
5개의 그룹
정보를 제공하는 응답 (1xx)
성공 응답 (2xx)
리다이렉트 응답 (3xx)
클라이언트 에러 응답 (4xx)
서버 에러 응답 (5xx)
 
https://http.cat/ 이라는 HTTP 코드에 대한 귀여운 사이트도 있습니다.
위키백과 기준
 
1xx
100(계속): 요청자는 요청을 계속해야 한다. 서버는 이 코드를 제공하여 요청의 첫 번째 부분을 받았으며 나머지를 기다리고 있음을 나타낸다.
101(프로토콜 전환): 요청자가 서버에 프로토콜 전환을 요청했으며 서버는 이를 승인하는 중이다.
2xx
200(성공): 서버가 요청을 제대로 처리했다는 뜻이다. 이는 주로 서버가 요청한 페이지를 제공했다는 의미로 쓰인다.
201(작성됨): 성공적으로 요청되었으며 서버가 새 리소스를 작성했다.
202(허용됨): 서버가 요청을 접수했지만 아직 처리하지 않았다.
203(신뢰할 수 없는 정보): 서버가 요청을 성공적으로 처리했지만 다른 소스에서 수신된 정보를 제공하고 있다.
204(콘텐츠 없음): 서버가 요청을 성공적으로 처리했지만 콘텐츠를 제공하지 않는다.
205(콘텐츠 재설정): 서버가 요청을 성공적으로 처리했지만 콘텐츠를 표시하지 않는다. 204 응답과 달리 이 응답은 요청자가 문서 보기를 재설정할 것을 요구한다(예: 새 입력을 위한 양식 비우기).
206(일부 콘텐츠): 서버가 GET 요청의 일부만 성공적으로 처리했다.
3xx
300(여러 선택항목): 서버가 요청에 따라 여러 조치를 선택할 수 있다. 서버가 사용자 에이전트에 따라 수행할 작업을 선택하거나, 요청자가 선택할 수 있는 작업 목록을 제공한다.
301(영구 이동): 요청한 페이지를 새 위치로 영구적으로 이동했다. GET 또는 HEAD 요청에 대한 응답으로 이 응답을 표시하면 요청자가 자동으로 새 위치로 전달된다.
4xx
400(잘못된 요청): 서버가 요청의 구문을 인식하지 못했다.
401(권한 없음): 이 요청은 인증이 필요하다. 서버는 로그인이 필요한 페이지에 대해 이 요청을 제공할 수 있다. 상태 코드 이름이 권한 없음(Unauthorized)으로 되어 있지만 실제 뜻은 인증 안됨(Unauthenticated)에 더 가깝다.
402(결제 필요): 이 요청은 결제가 필요합니다.
403(Forbidden, 금지됨): 서버가 요청을 거부하고 있다. 예를 들자면, 사용자가 리소스에 대한 필요 권한을 갖고 있지 않다. (401은 인증 실패, 403은 인가 실패라고 볼 수 있음)
404(Not Found, 찾을 수 없음): 서버가 요청한 페이지(Resource)를 찾을 수 없다. 예를 들어 서버에 존재하지 않는 페이지에 대한 요청이 있을 경우 서버는 이 코드를 제공한다.
405(허용되지 않는 메소드): 요청에 지정된 방법을 사용할 수 없다. 예를 들어 POST 방식으로 요청을 받는 서버에 GET 요청을 보내는 경우, 또는 읽기 전용 리소스에 PUT 요청을 보내는 경우에 이 코드를 제공한다.
406(허용되지 않음): 요청한 페이지가 요청한 콘텐츠 특성으로 응답할 수 없다.
5xx
500(내부 서버 오류): 서버에 오류가 발생하여 요청을 수행할 수 없다.
501(구현되지 않음): 서버에 요청을 수행할 수 있는 기능이 없다. 예를 들어 서버가 요청 메소드를 인식하지 못할 때 이 코드를 표시한다.
502 (Bad Gateway, 불량 게이트웨이): 서버가 게이트웨이나 프록시 역할을 하고 있거나 또는 업스트림 서버에서 잘못된 응답을 받았다.
503(서비스를 사용할 수 없음): 서버가 오버로드되었거나 유지관리를 위해 다운되었기 때문에 현재 서버를 사용할 수 없다. 이는 대개 일시적인 상태이다.
504(게이트웨이 시간초과): 서버가 게이트웨이나 프록시 역할을 하고 있거나 또는 업스트림 서버에서 제때 요청을 받지 못했다.
 
 
 
참고
https://developer.mozilla.org/ko/docs/Web/HTTP/Status
https://axios-http.com/kr/docs/handling_errors

코드로 대화하자 - HTTP 상태 코드

댓글