본문 바로가기

반응형

분류 전체보기

(218)
[REST] URI 네이밍 가이드 REST API에서는 URI를 통해 리소스를 표현합니다. 작성한 URI를 가지고 필요한 Resource를 호출합니다. 동사 대신 명사를 사용합니다. 그 이유는 명사를 사용하면 리소스의 속성을 표현할 수 있기 때문입니다. http://localhost:8080/member/getUser http://localhost:8080/member/deleteUser 계층 관계를 표현하려면 슬래시(/) 기호를 합니다. http://localhost:8080/member/id http://localhost:8080/member/info URI 주소 마지막에 슬래시(/) 기호를 사용하면 안됩니다. http://localhost:8080/member/id/ http://localhost:8080/member/info/ 길..
[REST] 리소스 REST의 네이밍은 개발자가 다루는 리소스(resource)를 기준으로 한다. 문서나 이미지 등과 같이 어떠한 데이터도 네이밍에 사용되는 리소스로 활용될 수 있다. 리소스 데이터는 싱글턴 또는 컬렉션으로 존재할 수 있다. 즉 단수 혹은 복수로 표현될 수 있다. users // is a collection resource user // is a singleton resource 싱글턴과 컬렉션 리소스의 표현 방식을 살펴보자. 리소스는 하위 컬렉션을 포함할 수 있다. 예를 들어 다양한 명품 브랜드가 입접된 온라인 명품 편집샵 서비스가 있다고 가정해보자. 특정 브랜드(brand)의 하위 컬렉션 리소스인 제품(products)은 URN로 다음과 같이 표현될 수 있다. /brands/{brandId}/produc..
[중고거래장터 -5] URL 디자인 그리고 Spring Security URL 디자인 수정을 했다. BEFORE AFTER 수정 시 중점적으로 생각한 부분은 다음과 같다. 메소드와 URL 두 개 요소로 어떤 기능을 수행하는지 쉽게 파악할 수 있도록 한다. URL을 통해 자원(resource)의 흐름을 명확히 파악할 수 있도록 한다. 로그인 페이지에서 아이디/비밀번호 찾기로 흘러가는 부분의 URL은 네이버(Naver)에게 힌트를 얻었다. URL을 어떻게 하면 간결하게 작성할 수 있을까 고민하다가 다른 서비스를 참고하기로 했다. 그렇다고 여러 서비스를 동시에 참고하면 혼란스러울까 싶어 네이버 하나만 참고하기로 했다. 처음에는 '문의하다'의 의미를 가지고 있는 영어 'inquiry'를 사용했지만, 해당 URL을 마주했을 때 직관적으로 어떤 기능일 것이라는 추측이 어렵다고 판단했다..
[Spring] @PathVariable을 통한 URI 설정 시 점(.) 이후의 값이 생략되는 현상 이메일 입력값에서 점(.) 이후의 값이 잘려서 넘어온다? 이메일 중복 확인 테스트가 계속 실패했다. 먼저 코드를 확인해보자. 아래 코드는 Controller 클래스의 메소드 그리고 해당 메소드의 테스트 코드이다. 구현 코드 @GetMapping("/email/{userEmail}") public ResponseEntity checkUserEmail(@PathVariable("userEmail") String userEmail) { try { service.isExistUserEmail(userEmail); } catch (EmailAlreadyExistsException e) { return new ResponseEntity(HttpStatus.CONFLICT); } return new ResponseE..
ambiguous handler methods mapped for... ambiguous handler methods mapped for... 말 그대로 요청 URI가 애매하기 때문이다. 애매한 이유는 중복되는 URI가 있기 때문일 것이다. 본인은 아래 코드를 통해 이 에러와 마주했다. @GetMapping("/exists/{userId}) public ResponseEntity checkUserId ... @GetMapping("/exists/{userEmail} public ResponseEntity checkUserEmail... 본인은 처음에 두 메소드의 URI가 서로 다르다고 생각했다. /exists/는 동일하지만 쿼리 스트링으로 들어가는 값이 다르기 때문에 다른 URI 아닌가? 하고 생각했다. 아니다. 두 메소드의 URI는 동일하다. /exists/ 까지가 URI..
[중고거래사이트 - 4] 제대로 만든다는 것은 무엇일까 개발 일정표에 따르면 로그인 기능을 구현했어야 했지만, 기존에 구현했던 회원가입 기능 보수 공사에 대부분의 시간을 할애했다. 보수 공사 내역은 다음과 같다. Controller 클래스 URI 형식 수정(RESTful하게?) ResponseEntity 클래스를 활용한 메소드 리스폰스 형태 수정 커스텀 RuntimeException 클래스 생성 및 활용 메소드 구현부에 있는 기존의 if-else 구문을 try-catch 구문으로 교체 코드 변경에 따른 테스트 클래스 코드 수정 및 테스트 그래도 로그인 기능 구현을 시작했다는 조금의 위안을 얻기 위해 로그인 페이지 작성은 했다. 거기까지만. 사실 기존의 회원가입 기능에 사용된 코드도 문제없었다. 그러니까 일단 동작은 한다. 그리고 나는 그것이 마음에 들지 않았..
[중고거래사이트 - 3] MockMVC를 통한 테스트 프로젝트를 시작하면 하루하루가 배움의 연속이다. 이번 프로젝트에서 MockMVC를 처음 사용했는데, 말 그대로 가짜(mock) mvc 환경을 조성한다. 덕분에 서버를 실행시키는 수고를 거치지 않고 Controller 클래스 기능 테스트를 할 수 있다. 사실 아직까지 테스트 클래스 작성의 실효성이 크게 와닿지 않는다. 하지만 좋다는 것은 알겠다. 테스트를 통해 밑바닥부터 튼튼한 서비스를 만들고 있다는 느낌을 얻을 수 있다. 그리고 이는 자신의 코드에 대한 자신감으로 이어지는 것 같다. 다. 꼼꼼한 테스트 구현이 가능하도록 연습해야겠다. 다시 MockMVC로 돌아가서, 아이디 중복체크 기능을 테스트하면서 HTTP 상태 코드 200을 반환하는 여부를 확인했더니 잘 진행되었다. 그렇게 넘어가려던 찰나, 가만히 ..
[중고거래사이트 - 2] 테이블 재구성 및 Git-Flow 모델로 구현 테이블 재구성 사용자 정보를 담는 테이블 설계를 잘못했다. PK로 int값을 저장하도록 했는데, 생각해보니 아이디가 충분히 고윳값이 될 수 있다. 왜 처음부터 아이디를 PK로 사용할 생각을 하지 못했을까? 테스트 클래스 작성 시 이상한 부분을 발견해서 기존 테이블을 삭제하고 다시 생성했다. 테이블이 몇 개 없는 데다 여러 제약조건이 얽혀있어서 처음부터 작업하는 것이 더 빠르겠다고 판단했다. 또한 채팅 관련 로직을 처리할 세 개의 테이블을 추가로 생성했다. 이 문제는 유스케이스를 수정하면서 발견했다. 처음부터 체계적으로 기능 정리를 했더라면 반복된 작업에 의한 시간 낭비가 없었을 것이다. 반성하고 다음부터는 이런 일이 없도록 하자. 고칠 수 있는 것은 확실히 고치자. Git-Flow 모델 Git-Flow ..

반응형