Rest Api는 쓰기 어렵다. 근데 Http Api도 어렵다.

Rest Api를 공부하다 보면 느끼는 것이 Restful하게 개발한다는 것은 굉장히 어렵다는 것이다.

 

Rest Api. 지켜야 될게 왜 이렇게 많아?

 

Rest Api를 구축할 때 딜레마에 빠진다.

A 방법, B 방법 다 올바르지 않기 때문이다. 

그리고 개발 과정에서 이 룰을 다 지키자니 개발 생산성이 떨어진다.

 

결국 Http Api 정도만 지키자란 식으로 갈아타게 된다.

Http Api만 지킨다는 것은 프로젝트의 앞뒷단의 강결합된 단점은 내버려두고

알아먹기 좋은 코드, 클린 코드만 지켜보자라는 취지가 강한 것 같다.

 

그렇다고 Http Api는 쉽나?

 

Http Api는 기존 RequestMapping 하나로 처리하던 것을 Http Method를 세분화해서 처리하자는 방식인데

이마저도 어렵다. 

 

Get 메소드는 정보를 조회하는 메소드.

Post 메소드는 데이터를 삽입하는 메소드.

Delete 메소드는 데이터를 지우는 메소드.

Put 메소드는 데이터를 수정하는 메소드.

 

각각의 메소드는 이름 그대로 CRUD 측면에서 설명되고 있다. 다만 이 룰이 굉장히 애매해질 때가 있다.

 

문제점 1 - 모든 곳에 Http Api의 의미가 통하는 것은 아니다.

 

로그인, 로그아웃에 관한 기능이다. 로그인은 삽입, 삭제도 아니고 "로그인 정보를 조회하는 것이니 Get으로 해야 하나?" 싶은데 보안이 취약해서 껄끄럽다. 그래서 보안이 그나마 좋은 Post로 하자니 "Post는 데이터 삽입이잖아?"라는 생각이 든다.

 

문제점 2 - 비슷한 의미에서의 Http Api

 

Post 메소드와 Put 메소드는 기능이 비슷한데 왜 구별하나? 어떻게 구별해서 사용하나?

 

해결방법

 

이러한 문제들의 뿌리는 Http 메소드를 지나치게 CRUD 관점에서 설명했다는 점에서 시작한다. 그리고 어떠한 방식을 채택할 지는 개발자마다 굉장히 주관적이라는 것이다. 구글링을 해본 결과 Http 메소드를 올바르게 쓰기 위해선 CRUD 관점이 아닌 보안과 멱등성에 우선순위를 둬야 한다.

 

멱등성 - "동일한 요청을 한 번 보내는 것과 여러 번 연속으로 보내는 것이 같은 효과를 지니고, 서버의 상태도 동일하게 남을 때, 해당 HTTP 메서드가 멱등성을 가진다."

 

문제점 1에서의 로그인 문제를 얘기해보자.

보안이 Get 보다는 강한 Post로 써야 한다. CRUD 관점을 포기하고서 말이다.

로그인이 아닌 로그아웃은 어떤가? 스택오버플로우에서도 아직도 Get을 사용해야 한다는 사람도 있고 Post로 사용해야한다는 사람도 있다. 지극히 개발자마다 주관적인 부분이다.

 

문제점 2의 해결방식을 얘기해보자.

Post 빼고 다른 메소드는 전부 멱등성을 지닌다. 그 말은 요청의 결과가 항상 동일하다는 것이다.

 POST는 매번 새로운 자원을 만드는 반면 PUT은 해당 자원이 이미 있다면 데이터만 덮어쓰기 한다. 즉, 요청을 한번하든 여러번하든 결국 서버의 상태는 같아진다. 그래서 PUT은 멱등성을 가지는 HTTP 메서드이다.

결과가 다를 수도 있을 때는 Post를 사용해야 한다.

그러한 관점에서 Put은 항상 결과가 동일 할 때 Post는 결과가 동일 하지 않을 때로 구별해서 사용하면된다. 

 

 

 

주관적 결론

 

Api를 올바르게 만들 때 오답은 수두룩 하지만 정답은 존재하지가 않는다.

차라리 Rest Api는 로그인 기능 같은 기능이 들어간 곳은 룰을 좀 완화해서 개발하고 CRUD 기능만을 가진 프로젝트에서만 룰을 지켜가며 구현하는 것이 맞다. 또한 CRUD 클래스 파일과 분리시켜 작업하는 것이 추후에 지속발전가능한 웹개발이 되지 않나 생각이 들었다.