Slack의 API 디자인 원칙

#네트워크/웹

1. 하나의 API에는 한가지 일만 시킨다.

하나의 API에 여러가지 기능을 집어넣다보면 당장은 편할 수도 있다. 하지만, 장기적으로 관리도 힘들어지고 클라이언트 측에서도 활용하기 어려워진다.

API를 단순하게 설계하고, 문서화에 신경을 쓴다. 샘플코드같은걸 첨부해서 클라이언트 개발자가 바로 보고 이해할 수 있게 해라.

slack에서는 15분 안에 이해하고 사용할 수 있게 하는 것을 지향한다.

문서를 자세히 보지 않아도 그 기능을 대강은 유추할 수 있게끔 uri명과 input/output를 짜놓는다.

api가 실패했을때 그 사유를 명확하게 알려줘라.

예를 들어, invalid_name보다는 name_too_long, name_too_short이 좋다.

예를 들어, 데이터가 수백,수천개가 넘는 데이터셋의 listup API는 페이지네이션을 적용해야 한다.

규모가 큰 컬렉션 안에 다른 대형 컬렉션을 중첩하는 것은 좋지 않다. 페이지네이션도 어려워지고, 성능 최적화도 힘들다.
가급적 분리한다.

상식적인 선에서 rate limit도 걸면 좋다.

이전과 코드 호환성을 파괴하는 브레이킹 체인지가 되도록 발생하지 않도록 한다.
클라이언트 개발자들을 위해서...