귤까먹는 코끼리 개발자

개인 프로젝트 진행 중 공연장에 등록된 hall을 리스트로 조회하는 API를 구현하면서 각 hall에 설정된 좌석수를 간단히 보여주고 싶었다.이 때 모든 hall 리스트가 보여지더라도, 모든 hall에 대한 좌석 세부 정보를 확인하지 않을 거라 생각하기 때문에 좌석 정보를 조회하는 부분과 hall을 조회하는 부분을 나누어 필요하지 않은 데이터까지 로딩하지 않는 목표를 세웠다. 공연장과 공연장에 존재하는 홀, 홀에 존재하는 좌석 이렇게 세개의 테이블은 서로 연관관계를 가지는 테이블로 구성되어있고홀에 존재하는 좌석 수를 구하는 방법 중 4가지 방법을 고안하고 고민했었다. 고민했던 4가지 방안 1. 공연홀을 조회하고, 각 좌석의 리스트 개수를 조회하기 2. 공연홀을 조회한 후 각 공연 홀에 대한 좌석 수 카운..

Put API는 CURD중 D(Delete)의 역할을 수행하게 된다. 리소스를 삭제하고, 없다면 아무것도 일어나지 않는다. 삭제 된 데이터이든 현재 있는 데이터든 삭제하는 것은 동일하기 때문에 멱등성을 가지고 있지만, 삭제하는 순간 데이터가 삭제되기 때문에 안정성은 가지고있지 않다. DataBody의 경우 넣을 순 있지만, 대부분 Unique값을 가지고 삭제시키기 때문에 사용하는 것을 권장하지는 않는다고 한다. @DeleteMapping("/path") : @DeleteMapping Annotation은 @RequestMapping(path = " ", method = RequestMethod.PUT) 와 같은 기능을 한다. 실제 데이터베이스를 연동하여 사용 중인 웹 사이트에서는 이 기능을 통해 데이터베..

Put API는 CURD중 C(Create)/U(Update)의 역할을 수행하게 된다. 리소스가 없는 경우 생성하고, 있다면 업데이트 한다. 처음 한번은 생성되고, 그 다음은 계속해서 기존 것을 업데이트하기 때문에 데이터는 항상 하나이며 같은상태를 유지하기 때문에 멱등성을 지녔다. 하지만 잘못된 데이터가 전송되더라도 업데이트 시키기 때문에 안정성은 지니지 못한다. [POST와 PUT의 차이] Post는 매번 생성하고, Put은 없으면 생성하고 있으면 업데이트를 한다는 점에서 차이를 드러낸다. 이러한 역할의 차이 때문에 Post는 멱등성이 없고, Put은 멱등성을 가지고 있다. Put 방식도 Json 방식으로 데이터를 주고 받게 되는데, Json 방식에 대해 간결한 설명은 아래 포스팅에 있으니 참고하면 된..

Post API는 CURD 중 C(Create)의 역할을 수행하게 된다. 즉, 리소스의 생성 및 추가를 위해 사용하는 것이다. 또한 DataBody에 데이터를 담아서 보내고, 생성 된 데이터를 전달받기 때문에 QueryParameter를 사용할 수는 있지만 보통은 사용하지 않는다. [POST와 PUT의 차이] Post는 매번 생성하고, Put은 없으면 생성하고 있으면 업데이트를 한다는 점에서 차이를 드러낸다. 이러한 역할의 차이 때문에 Post는 멱등성이 없고, Put은 멱등성을 가지고 있다. Post API를 사용하기에 앞서, 주로 web에서 데이터를 주고 받을 때 xml이나 Json 형태로 주고 받는데, 거의 대부분은 Json를 사용한다. Json의 형태는 다음과 같다. { "key" : "value..

Get API는 CURD중 R(Read)의 역할을 수행하게 된다. 즉 리소스의 취득을 위하여 사용하는 것이다. 동일한 요청을 한 번 보내는 것과 여러 번 연속으로 보내는 것이 같은 효과를 지니고, 서버의 상태도 동일하게 남기때문에 멱등성을 지녔다. @RequestMapping("/path") : url의 뒷 경로 값을 지정함 ex) http://localhost:port/path @GetMapping(path="/path2") : RequestMapping에서 지정해준 경로의 뒷 경로값을 지정함 (path = 을 생략하고, @GetMapping("/path2")로 바로 경로를 지정할 수 있음 ex) http://localhost:port/path/path2 @RequestMapping(path="/pat..