Well-Known URI를 정의하고 싶다면

1 hour ago 1

클라이언트가 이미 사이트를 알고 있고 사이트 전체의 정보를 효율적으로 찾아야 할 때 Well-Known URI가 가장 잘 맞음
robots.txt처럼 중앙 위치에 정책을 두면 반복 확인을 줄일 수 있지만, change-password처럼 사이트 전체 상호작용을 여는 용도로도 쓰일 수 있음
실제 URL을 전달할 수 있는 프로토콜이 Well-Known URI를 쓰면 서비스와 사이트가 1:1로 묶여 배포와 라우팅이 경직됨
발견 메커니즘이나 콘텐츠 메타데이터에 적용할 때는 시작 호스트명, 검색 위치, 리다이렉트, 다중 게시자 사이트 같은 운영 구조를 먼저 따져야 함
기존 루트 고정 경로에서 옮기려면 전환 계획이 필요하고, http·https 외 스킴까지 명시해야 등록 성공 가능성이 높아짐

Well-Known URI가 잘 맞는 상황

Well-Known URI specification의 저자 중 한 명이자 registry의 Designated Expert인 Mark Nottingham은 Well-Known URI를 언제 쓰면 좋은지 실무 기준을 공유함
이 기준은 모두 등록 요건은 아니며, 좋은 관행에 가까움
Well-Known 위치는 클라이언트가 이미 사이트를 알고 있고, 그 사이트 전체에 대해 무언가를 발견하거나 상호작용해야 할 때 적합함
- 여기서 사이트는 기술적으로 (scheme, host, port) 튜플인 origin을 뜻함
robots.txt는 RFC보다 먼저 존재했지만, Well-Known 공간을 예약하게 된 주요 이유 중 하나였음
- 크롤러는 사이트의 접근 정책을 알아야 함
- 중앙 위치에 정책을 두면 모든 응답마다 헤더와 콘텐츠를 확인하지 않아도 됨
Well-Known 위치가 반드시 정책만 담아야 하는 것은 아님
- 클라이언트가 사이트를 이미 알고 있고 사이트 전체에 대해 학습하거나 상호작용해야 하는 메커니즘이면 후보가 될 수 있음
- change-password Well-Known 위치는 클라이언트가 사이트의 비밀번호를 변경할 수 있게 함

일부 설계는 실제 문제 때문이 아니라 그렇게 해야 할 것처럼 보여서 Well-Known 위치를 지정함
등록 공간에 항목이 생긴다고 해서 정당성이나 채택률이 따라오지는 않음
- Well-Known 위치는 “클라이언트가 사이트를 알고 있고, 사이트 전체에 필요한 것이 있다”는 특정 문제를 해결함
- 프로토콜에 그런 문제가 없다면 등록은 새 문제를 만들 수 있고, 기대한 채택으로 이어지지 않음
어떤 제안은 Well-Known 위치를 사실상 URL 단축기처럼 사용함
- 프로토콜에서 전체 URL을 전달하지 않고 관련 사이트만 전달함
- Well-Known 위치가 나머지 경로를 채움
이 패턴은 서비스와 사이트를 1:1 관계로 고정함
- 배포가 여러 서비스를 필요로 하면 다른 사이트를 만들어야 함
- 사용자를 적절한 사이트로 보내는 별도 방법도 필요해짐
프로토콜이 정말 호스트명만 전달할 수 있다면 Well-Known 위치 사용이 타당할 수 있음
실제 URL을 사용할 수 있다면 굳이 Well-Known 위치를 쓰지 않는 편이 낫고, 편의나 공식적인 느낌 때문에 선택하면 배포가 불필요하게 경직됨

많은 프로토콜은 “사용자가 이미 사이트를 안다”는 전제로 Well-Known 위치를 발견 메커니즘에 사용하려 함
실제로는 사용자의 현재 상호작용 범위와 발견이 일어나는 위치가 어긋날 수 있음
- 클라이언트가 login.example.com에서 시작했다면 Well-Known 위치를 그 사이트에서 찾아야 하는지, example.com에서 찾아야 하는지 문제가 됨
- 한쪽에서 다른 쪽으로의 리다이렉트를 따라야 하는지도 정해야 함
- 게시자는 상호운용성을 보장하기 위해 어떤 사이트에 Well-Known 위치를 제공해야 하는지도 불명확할 수 있음
이 문제는 프로토콜이 실제 웹사이트 자체를 다루지 않고, HTTP를 다른 목적에 활용할 때 특히 중요함
등록 가능한 도메인 이름의 Well-Known 위치를 apex에 두도록 지정하고 싶을 수 있지만, 일부 환경에서는 운영상 어려울 수 있음
이런 범주의 프로토콜은 무엇을 발견하는지와 사용자가 어디서 시작하는지를 함께 고려해야 함
- 웹 아키텍처에 대해 과도하게 가정하지 않고 올바른 호스트명을 안정적으로 찾는 방법을 정해야 함

일부 프로토콜은 사이트 콘텐츠를 학습하기 위해 Well-Known 위치를 사용하려 함
/robots.txt가 이런 방식으로 동작하지만, 이 패턴이 모든 콘텐츠 메타데이터에 쉽게 맞지는 않음
많은 사이트는 여러 게시자를 대표함
- 예로 과거의 /~username/ 관례가 있음
중앙 위치에 콘텐츠 메타데이터를 두면 두 가지 문제가 생김
- 해당 메커니즘이 개별 사용자에게 사실상 사용 불가능해질 수 있음
- 관리자가 사용자의 제어를 지원하고 감독하기 위한 복잡한 인프라를 만들어야 할 수 있음
이런 배포는 편의성과 세분성 사이의 절충을 드러냄
- HTTP 응답 헤더나 콘텐츠 자체에 병렬 메타데이터 메커니즘을 만들 필요가 생길 수 있음
- 서로 다른 메타데이터 부착 방식도 정리해야 함
콘텐츠 메타데이터에 Well-Known 위치를 못 쓰는 것은 아니지만, 예상보다 훨씬 많은 작업이 필요할 수 있음
리소스 메타데이터에 Well-Known 위치를 쓰는 프로토콜은 웹의 다양한 사이트 구조를 고려해야 함

이미 루트의 고정 위치를 정의한 제안도 있음
- /robots.txt처럼 Well-Known 위치를 나중에 알게 된 경우가 해당함
이런 경우 기존 배포를 위한 전환 계획이 필요함
- 제안자는 현재 배포 기반에 과도하게 집중하는 경향이 있음
- 합리적인 기간 동안 좋은 전환 계획을 두면 Well-Known 위치로의 이동을 관리할 수 있음
많은 제안은 http와 https URL을 암묵적으로 가정함
Well-Known 위치는 다른 URL 스킴에도 적용되므로, 관련 스킴을 명시적으로 열거해야 함
Well-Known 위치는 등록해야 함
- 해당 링크에는 언제 등록해야 하는지와 이름을 고르는 방법에 대한 지침이 있음
- 이 등록 지침은 앞선 조언과 달리 실제 등록 성공 가능성에 영향을 줌