새 표준을 만들기 전에 표준 확인

게시물Check for Standards Before Creating a New One은 Qvault에 처음 등장했습니다.

저는 최근 API의 캐싱 시스템을 우회하는 기능을 요청하는 팀의 백로그 게시판에 티켓을 열었습니다. 컨텍스트를 위해 우리 프런트 엔드 팀은 우리 팀의 API를 사용하여 ElasticSearch에 상당히 많은 요청을 하고 API 게이트웨이의 기능 중 하나는 ~30초 동안 많은 집계 결과를 캐시하는 것입니다. 때때로 그들은 ~30초 캐싱 창 내에서 동일한 쿼리 두 개를 실행해야 하고 업데이트된 결과 세트를 원합니다.

열린 요청은 "특정 쿼리에 대한 캐싱을 비활성화하려면 API에 매개 변수가 필요합니다"와 같은 내용을 읽었습니다. REST-ish-ful API에서 작업할 때 이를 수행할 수 있는 대략적인 방법math.MaxInt이 있으며 즉시 떠오르는 몇 가지 방법은 다음과 같습니다.

A ?cache=false 쿼리 매개변수

A resource/no-cache 엔드포인트 확장

A cache: false HTTP 헤더

A "cache": false" 본문의 JSON 페이로드

알고 보니 이미 이런 종류의 표준인 Cache-Control request directives이 있습니다.

Cache-Control: max-age=<seconds>
Cache-Control: max-stale[=<seconds>]
Cache-Control: min-fresh=<seconds>
Cache-Control: no-cache
Cache-Control: no-store
Cache-Control: no-transform
Cache-Control: only-if-cached

표준 헤더Cache-Control: no-store를 사용하면 API 설계 결정이 줄어들어 작업이 더 쉬워질 뿐만 아니라 API 클라이언트가 공통 작업을 수행하는 새로운 방법에 놀라지 않게 됩니다.

그러나 상당히 잘 지원되는 표준을 사용하기로 결정했다고 해서 사용자가 기대할 다른 표준이 없다는 의미는 아니라는 점을 지적하고 싶습니다. 또한 사용자가 선택한 표준의 존재를 알고 있다는 의미도 아닙니다.

https://xkcd.com/927/

API의 동작이 "표준"또는 "예상"이라고 생각하는지 여부에 관계없이 동작을 문서에 추가하기만 하면 됩니다. 저에게는 Readme.md의 다음 스니펫이 필요한 전부였습니다.

## Cache busting

If you don't want your query cached, use the Cache-Control header.
 Cache-Control: no-store

읽어 주셔서 감사합니다. 이제 과정을 수강하십시오!

기술 분야의 고임금 직업에 관심이 있으십니까? 실습 코딩 과정을 마친 후 인터뷰를 시작하고 멋지게 통과합니다.

Start coding now

질문?

질문이나 의견이 있으면 트위터에서 나를 팔로우하고 연락하십시오. 기사에서 실수를 한 경우 반드시 let me know 수정하여 수정할 수 있도록 해주세요!

Subscribe 받은 편지함으로 바로 전달되는 더 많은 코딩 기사를 보려면 내 뉴스레터로 보내십시오.