Skip to content
isdnetworks
Go back

소셜 동작마다 엔드포인트가 하나씩이었다

소셜 플랫폼 연동 API 가 여러 개였다.

로그인
좋아요 여부 갱신
친구 초대
친구 초대 시간 조회
공유 이미지 조회
좋아요 설정

동작 하나에 엔드포인트 하나다. 하나로 묶을 수 있지 않나 싶었다.

Table of contents

Open Table of contents

하나로 묶는다면

묶으면 이렇게 될 것이다.

POST /social
{
  "action": "invite",
  "params": { ... }
}

action 으로 분기하니 엔드포인트가 하나로 준다. 그런데 이 명세는 굳이 나눠 두었으므로 그 이유가 있을 것으로 봤다.

비교 — 나누기와 묶기

나눠 두면 URL 만 보고 무엇을 하는지 안다.

/facebook/inviteGift        친구 초대
/facebook/getImgPath        공유 이미지
/facebook/setLike           좋아요 설정

묶으면 POST 본문을 봐야 안다. 또 하나는 접근 제어다. 나눠 두면 특정 경로만 막거나 제한할 수 있다. 묶으면 본문을 봐야 분기하므로 앞단에서 못 한다.

로그도 갈린다. 나눠 두면 access_log 에 경로별 호출 수가 그대로 집계된다. 묶으면 전부 한 경로로 뭉쳐서 어느 동작이 얼마나 호출됐는지를 모른다.

반대로 묶는 것이 나아 보이는 경우도 있다. 동작이 아주 많고 자주 늘어나면 매번 경로를 추가하는 것이 번거롭다. 값 하나를 추가하는 쪽이 가볍다. 여기는 여섯 개이고 자주 늘어나는 것 같지도 않아서 나누는 쪽이 자연스러워 보였다.

조회와 설정이 짝이었다

목록을 다시 보니 짝이 보였다.

초대            /inviteGift
초대 시간 조회  /FriendInviteInfo

좋아요 설정     /setLike
좋아요 여부     로그인 응답의 is_like

하는 것과 확인하는 것이 따로 있다. 확인이 필요한 이유는 그 동작이 우리 쪽에서 완결되지 않기 때문이다. 외부에서 실제로 됐는지를 물어봐야 안다.

시간을 초로 줬다

초대 시간을 왜 조회하는지 생각해 봤는데 설명에 이렇게 있었다.

invite_date   초대 시간, 초로 반환

초 단위로 준다. 날짜가 아니라 초로 주는 것은 경과 시간 계산에 쓰이는 것 같고 지금에서 초대 시간을 빼서 경과가 일정 이하면 다시 초대 못 하는 쿨다운으로 보인다.

날짜 문자열로 주면 클라이언트가 파싱하고 시간대를 맞춰야 하는데 초로 주면 빼기만 하면 된다. DateTime::createFromFormat 으로 형식을 맞출 일도 date.timezone 을 신경 쓸 일도 없다. 보내는 쪽은 time() 을 그대로 담고 받는 쪽은 date() 에 넘긴다. 시간대 문제가 없다는 것이 특히 좋아 보인다.

경로 이름이 섞여 있었다

목록을 보다 하나 걸렸다.

/facebook/inviteGift
/facebook/FriendInviteInfo
/facebook/getImgPath
/facebook/setLike
/facebook/login

대소문자 규칙이 섞여 있다. inviteGiftgetImgPath 는 첫 글자가 소문자인데 FriendInviteInfo 는 대문자다.

한 사람이 한 번에 지었으면 안 섞였을 것 같다. 시간을 두고 추가되면서 섞인 것으로 보인다. 경로는 한 번 공개되면 바꾸기 어려운데 클라이언트가 이미 그 주소를 쓰고 있기 때문이다. 바꾸려면 RewriteRule301 을 두고 한동안 양쪽을 받아야 한다.

다만 이것이 실제로 문제인지는 잘 모르겠다. 동작에는 영향이 없고 호출하는 쪽이 정확히 적기만 하면 된다. 읽을 때 조금 걸릴 뿐이다. 고치는 비용과 남겨 두는 불편 중 어느 쪽이 큰지는 상황마다 다를 것 같다.

정리


Share this post on:

Previous Post
같은 것을 여섯 가지 이름으로 부르고 있었다
Next Post
서버마다 빌드 도구 버전이 달랐다