REST API 적용

나름대로 REST API에 대한 규칙을 세우고 적용해서 API를 개발했다.

 

개발자마다 정의하는 REST API의 규칙은 다들 조금씩 범주가 다르다. 각자 정의한 REST API 규칙을 따를 뿐이었다. 누군가는 모든 메소드가 post로 작성되더라도 REST API 라고 한다. 누군가는 실제 Database 기준으로 CRUD에 따라 method를 활용해야 한다고 한다. 또 누군가는 client 기준으로 method를 정의해야 한다고 한다. 대기업들도 마찬가지로 REST API 제작자가 설계한 원리를 그대로 따르는 회사는 잘 없다. 그래서 이번 기회에 내 나름대로 REST API에 대해서 최대한 공부해서 규칙들을 정의하고 따랐다.

 

내가 지킨 규칙들은 다음과 같다.

1. URI는 소문자로 적을 것

2. URI는 단어 분리가 필요할 때, 대문자로 연결하지 말고 하이푼으로 사용할 것

3. CRUD 여부에 따라 method를 다르게 해야 한다.

4. URI에 행위 여부에 대한 동사가 들어가면 안된다. (method로 명시해야함)

5. URI 마지막에 슬래시를 넣지 않는다.

6. 사용자 기준으로 Method를 활용한다. (사용자 기준으로 데이터 삭제라면, delete 메소드를 활용한다. 비록 컬렉션 Flag 값만 변경될 뿐이더라도 말이다.)

 

더 많은 규칙들도 있겠지만, 이 정도의 규칙을 따르기로 했다. 그리하여 실제로 작성된 API를 간략하게 보면 다음과 같다.

 

그런데 간혹 API를 정의하기 모호한 경우가 있다. 예를 들어, 좋아요 기능이다. 나는 좋아요 API가 호출 될 경우, 좋아요를 하지 않은 상태라면 좋아요가 생기도록 한다. 반대로 좋아요를 하지 않은 상태라면 좋아요를 제거한다. 이 상황을 봐서는 어떤 때는 등록이며, 어떤 때는 삭제다. 이런 경우 참 모호하다. 이 상황에 대비해서 함께 모각코 하는 사람들과 토론을 하기도 했으나, 결론을 명확하게 내리지는 못했다 ㅜㅜ 혹시 아시는 분은 조언 부탁 드립니다.

 

그래서 나는 이러한 케이스에 대해서는  내 느낌이 post인거 같아서 post로 처리했다. 아마 이런 애매모호한 상황이 생기면 post로 처리할 것만 같다.

 

느낀점

REST API를 잘 사용하려고 노력해봤는데, 결국에는 빈틈이 보이게 되었다. 지방에 있는 개발 회사들은 모든 API에 대해서 post로 처리하기도 한다고 한다. ㅋㅋㅋㅋㅋㅋㅋㅋㅋ 뭐가 정답인지는 모르겠으나, 이건 알거 같다. 결국 특정 집단에서 사용하고 있는 기준을 따르는게 맞는거 같다.