요약

  • RFC 6690은 RFC 5988의 웹 링크 구조를 application/link-format 자원 표현으로 만들었다. RFC 5785에 따른 /.well-known/core가 제한된 서버의 기본 탐색 입구가 됐다.
  • 링크는 자원 유형 rt, 인터페이스 if, 콘텐츠 형식 ct, 최대 크기 추정치 sz를 담을 수 있다. 클라이언트가 조건을 붙여 찾을 수 있지만 서버에 필터 구현 의무는 없다.
  • 목록은 다음 요청의 목적지를 알려준다. 현재 측정값이나 동작 결과는 대상 자원이 별도로 응답한다. 2014년의 CoAP은 제한된 노드의 전송 모델에 자원 검색을 넣었다.

기계에는 안내 직원이 없다

사람은 화면에서 링크를 따라가며 필요한 정보를 찾는다. 건물 속 작은 제어기에는 화면도, 대신 클릭해 줄 사람도 없다. 온도와 조도 자원 또는 스위치를 찾으려면 네트워크 안에서 입구를 알아내야 한다. RFC 6690이 그린 환경은 8비트 마이크로컨트롤러와 저전력 통신망이다. 메모리와 통신량이 넉넉하지 않다. 경로를 제어기에 고정해 놓으면 장치를 바꾸거나 자원을 옮길 때 예전 주소가 계속 남는다.

표준이 정한 공동 출발점은 /.well-known/core다. 이 형식을 구현한 서버는 해당 프로토콜의 기본 포트에서 그 자원을 지원한다. GET에 대한 응답은 CoRE Link Format 링크 목록이다. 공개할 링크가 없으면 길이 0인 본문도 가능하다. 표준의 </sensors/temp>;rt="temperature-c";if="sensor" 예시는 대상 경로, 자원의 종류, 인터페이스를 짧게 묶는다. 조도 센서 링크를 골랐다면 클라이언트는 그 주소로 다음 요청을 보낸다.

첫 번째 GET은 지도를 받는다. 두 번째 요청은 실제 목적지에 간다. 지도에 센서가 보인다고 측정값이 이미 생긴 것은 아니다. 장치가 잠들어 있을 수도 있고, 대상 자원이 접근 권한을 따질 수도 있다. 공동 안내창은 어디로 갈지 찾는 비용을 낮추며 각 자원이 자기 주소에서 대답하도록 남겨 둔다.

헤더 밖으로 나온 링크

RFC 5988은 문맥 자원과 대상 자원을 유형이 있는 관계로 잇는 웹 링크 모델을 제시했다. RFC 6690은 HTTP Link 헤더와 닮은 표기법을 가져와 별도 자원 표현으로 내놓았다. 미디어 유형은 application/link-format이다. 대상 URI를 꺾쇠 안에 쓰고 속성을 덧붙이며 여러 링크는 쉼표로 나눈다. 작은 기계가 XML 구조를 크게 세우지 않고도 다음 목적지를 읽을 수 있는 크기다. 안내가 다른 응답의 헤더 구석에 붙어 있는 대신, 요청할 수 있는 자원으로 제공된다.

짧은 속성마다 맡은 일이 다르다. rt는 응용 프로그램이 정한 자원 유형이며, 온도 값처럼 무엇을 나타내는지 말한다. if는 그 자원과 상호작용할 인터페이스를 가리키며, 여러 자원 유형이 같은 인터페이스를 쓸 수 있다. ct는 콘텐츠 형식, sz는 GET으로 받을 표현의 최대 크기 추정치다. 작은 클라이언트는 sz를 보고 전송을 감당할지 판단할 수 있다. rt를 사람에게 보여 줄 이름으로 쓰는 설계가 아니다. 읽기 좋은 명칭에는 title이 따로 있다.

rel이 없는 링크에도 관계가 있다. 기본값 hosts는 링크의 문맥 서버가 대상을 호스팅한다는 뜻이다. 명시적인 관계와 anchor는 다른 맥락을 나타낼 수 있고, 링크 대상이 다른 서버에 있을 수도 있다. URI만 모아 놓고 관계와 문맥을 버리면 외부 설명을 로컬 자원으로 오해하기 쉽다. 몇 글자 아낀 표기 안에도 누가 무엇을 호스팅하는지가 담겨 있다.

모든 문을 한 번에 열 필요는 없다

서버는 /.well-known/core에 모든 센서를 한 줄로 나열할 의무가 없다. 어떤 링크를 넣고 어떻게 배열할지는 응용 프로그램이 정한다. /sensors라는 컬렉션 입구를 먼저 내고 그 안에서 온도와 조도 자원의 링크를 줄 수도 있다. 안내를 요청한 클라이언트마다 건물 전체의 주소록을 한 번에 보내지 않아도 된다.

클라이언트는 GET /.well-known/core?rt=light-lux처럼 원하는 자원 유형을 지정할 수 있다. 하지만 RFC 6690에서 필터 지원은 선택 사항이다. 빈 응답을 곧바로 “조도 센서가 없다”로 읽으려면 해당 서버가 그 조건을 실제 처리하는지 알아야 한다. rt와 if의 값은 응용 프로그램이 쓰는 어휘이지, 전 세계 장치 모델에 붙은 단일 번호 체계가 아니다.

절전 상태로 잠드는 센서가 많거나 연결 대역이 좁으면, 모든 클라이언트가 매번 모든 장치에 직접 물을 수 없다. RFC 6690은 다른 서버의 링크를 보관하는 자원 디렉터리도 그린다. 더 여유 있는 노드가 링크를 모아 검색하게 할 수 있지만, 디렉터리의 자세한 동작은 이 RFC 밖에 남겼다. 원래 서버가 설명을 제공하고, 디렉터리가 그 지도를 보관하고, 클라이언트가 목적지를 고르고, 실제 자원이 마지막으로 응답한다. 오래된 디렉터리 링크가 현재 센서 상태까지 보장하지는 않는다.

지도에도 관리자가 있다

작은 합의 몇 개가 연결됐다. RFC 5785는 잘 알려진 경로의 틀을 마련했고, RFC 5988은 링크 관계를 설명했으며, RFC 6690은 작은 서버용 본문과 공통 입구를 정했다. 2014년의 RFC 7252는 CoAP에 자원 검색을 담았다. 모든 센서를 한 중앙 등록부에 모은 설계가 아니다. 각 서버에서 어디부터 물을지 알려주는 설계였다.

서버는 어떤 링크를 공개할지 선택한다. 요청자의 신원과 권한에 따라 다른 목록을 돌려줄 수도 있다. 하지만 링크를 숨기는 것만으로 이미 주소를 아는 사람의 요청은 막을 수 없다. 실제 자원이 그 요청에 대한 접근 판단을 해야 한다. 링크의 출처가 중요하다면 안내를 보낸 서버도 인증해야 한다. 안내창의 주인, 복사본을 가진 디렉터리, 목적지 자원은 같은 역할이 아니다.

공식 문서 네 건은 링크 문법, 등록된 입구와 발견 절차를 보여준다. 특정 건물에서 실제 사용됐다고 말하려면 당시 장치 펌웨어와 /.well-known/core 응답, 이어지는 센서 요청이 필요하다. 처음의 제어기는 안내창에서 주소를 얻는다. 조도 값은 문 안쪽의 센서가 내놓는다.