해시 라우터를 사용할 때는 발생하지 않는 문제지만 브라우저 라우터를 사용하면 발생하는 문제입니다. 연관글 영역 1. 문제의 발견 SPA(Single Page Application)에서 라우팅을 할 때 1) 새로고침을 하거나 2) SPA의 'APP'가 있는 URL에 진입하지 않고 다른 주소부터 진입하려고 하면 404 에러가 나게 됩니다. 해시(#) 라우팅을 쓸 때야 결국 지정된 파일을 읽은 후 해시 라우터를 사용하므로 문제가 되지 않지만 브라우저 라우터를 쓸 때는 진입 파일이 없으니 어쩔 수가 없죠. 2. 해결 방법 이 문제를 해결하려면 해석할 수 없는 주소가 왔을 때 폴백(Fallback)하도록 구성해야 합니다. (참고 : Rick Strahl's Weblog - Handling SPA Fallback ..

전편에서 했던 "API 결과 리턴 공통화"는 좀 급하게 만들다 보니 빠진 것이 있는데......가장 중요하다고 할 수 있는 '결과 처리 클래스'가 공통화가 덜돼서 최종 결과를 출력하는 'ApiResultReady.ToResult()'를 호출할 때 출력할 객체를 따로 지정해야 했습니다. 이번엔 이 불편함을 고쳐봅시다. 1. 'ApiResultBaseModel' 수정'ApiResultReady'에서 하던 성공 실패 여부를 처리하기 위한 기능을'ApiResultBaseModel'으로 옮여야 합니다. 성공 문자를 저장해두고 이것과 비교하는 함수를 추가합니다. 12345678910111213141516171819202122232425262728293031323334353637383940414243444546474..

API의 결과를 줄 때 성공하면 약속된 모델을 전달하고 실패하면 실패에 약속된 모델을 전달하는 것이 일반적인 방법입니다.이 방법의 문제는 성공했을 때와 실패했을 때 구분이 매번 똑같을 수 없으니 프론트엔드(Front-end)에서는 이것을 구분하기 위한 작업을 그때그때 해야 합니다. 그래서 API결과를 알리기 위해 고정된 값을 하나 전달해주는 것이 좋습니다.API 결과용 베이스를 만들어 API를 리턴할때는 이 베이스를 상속받은 모델을 리턴하는 것이죠. 1. 필요한 정보API결과는 다음과 같은 경우가 있습니다. 성공 : 의도대로 API가 성공한 경우실패 : 서버에서 실패로 판단하는 경우. 백엔드(Back-end)와 협의된 정보를 전달한다.캐치 가능한 오류 : 서버에서 캐치한 오류(try~catch)알 수 없..