문서의 선택한 두 판 사이의 차이를 보여줍니다.
양쪽 이전 판 이전 판 다음 판 | 이전 판 다음 판 양쪽 다음 판 | ||
web:신규서비스 [2019/02/19 16:24] kwon37xi |
web:신규서비스 [2019/03/30 18:15] kwon37xi [API 설계] |
||
---|---|---|---|
줄 278: | 줄 278: | ||
===== API 설계 ===== | ===== API 설계 ===== | ||
- | * API 설계시 다중건 결과를 내는 경우 Paging 기반으로 요청을 받지 말고 | + | * API 설계시 다중건 결과를 내는 경우 Paging 기반으로 요청을 받지 말고 |
- | * 요청자 측에서 페이징 | + | * 더보기 |
+ | * 이 경우 페이지가 뒤로 늘어나도 전혀 성능저하가 발생하지 않고 균일하다. | ||
* 다음 페이지의 존재 여부를 알고자 한다면 '' | * 다음 페이지의 존재 여부를 알고자 한다면 '' | ||
+ | * '' | ||
+ | * '' | ||
* API 의 경우 호출자에 대한 정보를 HTTP Header 등에 주입하고 로그로 자세히 남기는 것이 좋다. 이는 SQL 구문도 마찬가지 이다. | * API 의 경우 호출자에 대한 정보를 HTTP Header 등에 주입하고 로그로 자세히 남기는 것이 좋다. 이는 SQL 구문도 마찬가지 이다. | ||
* 호출자 서비스 이름 | * 호출자 서비스 이름 | ||
줄 319: | 줄 322: | ||
* 오픈 예정일이 굉장히 밀도 높고 여러 팀이 엮인 프로젝트를 진행해야 할 경우 | * 오픈 예정일이 굉장히 밀도 높고 여러 팀이 엮인 프로젝트를 진행해야 할 경우 | ||
* Jira(혹은 관련 이슈 트래커)에 여러 팀별 이슈를 하나로 묶은 보드를 생성한다. (묶음의 조건을 만족시킬 수 있는 이슈 레이블 등이 필요할 듯) | * Jira(혹은 관련 이슈 트래커)에 여러 팀별 이슈를 하나로 묶은 보드를 생성한다. (묶음의 조건을 만족시킬 수 있는 이슈 레이블 등이 필요할 듯) | ||
+ | * 모든 팀을 통합하여 스프린트를 일괄로 잡는다. | ||
* Sprint 를 1주 단위 정도로 잘게 쪼개는 게 좋다. 목표를 명확히 가시화 한다. | * Sprint 를 1주 단위 정도로 잘게 쪼개는 게 좋다. 목표를 명확히 가시화 한다. | ||
* 스프린트당 통합 테스트를 목표로 정하는게 좋다. 허접해도 통합해서 뭔가를 보는게 좋다. | * 스프린트당 통합 테스트를 목표로 정하는게 좋다. 허접해도 통합해서 뭔가를 보는게 좋다. |