2.1.1 게시 클라이언트

게시물을 생성하는 적합한 Micropub 클라이언트:

• MUST x-www-form-urlencoded 요청 전송을 지원해야 합니다
• MUST [h-entry] 어휘를 지원해야 합니다
• 클라이언트가 파일 첨부를 업로드하여 게시물을 생성하는 경우, MUST 미디어 엔드포인트가 있는지 확인하고, 있다면 파일은 Micropub 엔드포인트가 아닌 미디어 엔드포인트로 전송해야 합니다
• SHOULD 서버 오류 메시지를 사용자에게 안내 메시지로 전달하는 등 친절하게 처리해야 합니다
• SHOULD 엔드포인트 탐색을 지원해야 합니다

2.1.2 편집 클라이언트

게시물을 편집하는 적합한 Micropub 클라이언트:

• MUST JSON 인코딩 요청 전송을 지원해야 합니다
• MUST [h-entry] 어휘를 지원해야 합니다

2.1.3 서버

적합한 Micropub 서버:

• MUST 인증의 헤더와 폼 파라미터 방식 모두를 지원해야 합니다
• MUST [h-entry] 어휘를 사용하여 게시물 생성을 지원해야 합니다
• MUST x-www-form-urlencoded 구문을 사용한 게시물 생성을 지원해야 합니다
• SHOULD 게시물 수정 및 삭제를 지원해야 합니다
• 게시물 수정을 지원하는 서버는 MUST JSON 구문과 source content query를 지원해야 합니다
• 미디어 엔드포인트를 지정하지 않은 서버는 MUST 게시물 생성을 위한 multipart/form-data 요청을 지원해야 합니다
• 미디어 엔드포인트를 지정한 서버는 MUST configuration query를 지원해야 하며, 그 외 서버도 SHOULD configuration query를 지원해야 합니다

2.2.1 클라이언트

Micropub 클라이언트는 게시물 생성을 비롯한 Micropub 요청을 전송하는 구현체입니다. 적합성 기준은 위의 적합성 클래스에 설명되어 있습니다.

2.2.2 서버

Micropub 서버는 Micropub 요청을 받아 게시물을 생성하고, 선택적으로 수정 및 삭제를 지원하는 구현체입니다. Micropub 서버는 미디어 업로드를 위한 미디어 엔드포인트를 별도로 지원할 수 있습니다. 적합성 기준은 위의 적합성 클래스에 설명되어 있습니다.

2.2.3 독립적

각 구현체는 서로 다른 당사자가 개발해야 하며, 자격을 갖춘 다른 구현체의 코드 재사용, 파생, 공유가 불가능합니다. 이 명세 구현과 무관한 코드 부분은 예외로 인정됩니다.

2.2.4 상호운용 가능

특정 기능에 대해, 서버가 클라이언트의 요청에 정의된 작업을 실행하고, 클라이언트가 해당 기능에 따라 서버의 예상 응답을 받으며, 서버 역시 클라이언트에 예상된 응답을 제공할 때, 클라이언트와 서버 구현은 상호운용이 가능한 것으로 간주합니다.

2.2.5 구현

구현(Implementation)은 다음 모든 기준을 충족하는 Micropub 클라이언트 또는 서버입니다:

• 명세의 해당 적합성 클래스를 구현함
• 일반 대중에게 다운로드 가능 소프트웨어 또는 호스팅 서비스 형태로 제공됨
• 실험적이지 않으며(즉, 넓은 사용자층을 대상으로 하며 일상적으로 사용될 수 있음)
• 웹사이트에서 주요하게 사용할 수 있을 만큼 적합함

2.2.6 기능

종료 기준 평가를 위해 다음 각 항목을 하나의 기능(Feature)로 간주합니다:

• 사용자 프로필 URL을 기반으로 Micropub 엔드포인트를 찾기
• HTTP Authorization 헤더에 액세스 토큰을 포함하여 요청 인증
• x-www-form-urlencoded 요청의 본문에 액세스 토큰을 포함하여 요청 인증
• 액세스 토큰에 하나 이상의 OAuth 2.0 scope 값이 있어야 게시물 생성이 가능함
• x-www-form-urlencoded 구문 및 하나 이상의 속성으로 게시물 생성
• JSON 구문과 하나 이상의 속성으로 게시물 생성
• 동일한 속성명이 여러 값으로 x-www-form-urlencoded 구문으로 게시물 생성
• 동일한 속성명이 여러 값으로 JSON 구문으로 게시물 생성
• 중첩된 Microformats2 객체를 포함하는 JSON 구문으로 게시물 생성
• 지정된 미디어 엔드포인트에 파일 업로드
• Micropub 엔드포인트에 multipart/form-data로 요청을 전송해 파일이 포함된 게시물 생성
• URL로 참조된 사진이 포함된 게시물 생성
• 이미지 대체 텍스트가 포함된 URL 참조 사진으로 게시물 생성
• 서버가 인식하지 못하는 속성이 포함된 요청으로 게시물 생성
• 게시물 생성 시 HTTP 201 Created와 Location 헤더 반환
• 게시물 생성 시 HTTP 202 Created와 Location 헤더 반환
• 게시물 수정 및 속성 값 모두 교체
• 게시물 수정 및 속성에 값 추가
• 게시물 수정 및 속성에서 값 제거
• 게시물 수정 및 속성 삭제
• 게시물 수정 시 HTTP 200 OK 반환
• 수정으로 게시물 URL이 변경될 경우 HTTP 201 Created 반환
• 게시물 수정 시 HTTP 204 No Content 반환
• x-www-form-urlencoded 구문으로 게시물 삭제
• JSON 구문으로 게시물 삭제
• x-www-form-urlencoded 구문으로 게시물 복원
• JSON 구문으로 게시물 복원
• 미디어 엔드포인트로 사진 업로드 후, 그 URL로 게시물 생성
• q=config로 Micropub 엔드포인트를 쿼리하여, 미디어 엔드포인트와 syndication 대상 조회
• q=syndicate-to로 Micropub 엔드포인트를 쿼리하여 syndication 대상 목록 조회
• 특정 속성 없이 게시물의 원본 콘텐츠를 Micropub 엔드포인트에서 조회
• 특정 속성만을 조회하며 게시물의 원본 콘텐츠를 Micropub 엔드포인트에서 조회

3.1.1 Form-Encoded 및 Multipart 요청

x-www-form-urlencoded 및 multipart/form-data 요청의 경우, Micropub은 명시적으로 다중 값 속성을 표시하기 위한 URL 인코딩 확장 형태를 지원합니다. 즉, 하나의 속성에 여러 값을 보낼 경우 속성명에 대괄호 []를 붙여야 함을 의미합니다.

예를 들어 "category" 속성에 여러 값을 지정하려면, category[]=foo&category[]=bar와 같이 요청에 포함시킵니다.

서버 측에서는 이를 내부적으로 배열 형태로 변환하는 것이 기대됩니다. 예를 들면, 동등한 JSON 표현은 다음과 같습니다:

{
  "category": [
    "foo",
    "bar"
  ]
}

이 방식은 multipart 요청에서도 동일하게 동작하며, 각 값이 요청의 별도 "part"에 포함되고 "name"은 Content-Disposition: form-data; name="category[]"와 같이 표시됩니다.

x-www-form-urlencoded 확장의 범위는 배열을 표시하는 대괄호 추가에만 해당함을 참고하세요. foo[0] 또는 foo[bar] 같은 구문은 지원되지 않으므로, 더 복잡한 객체를 전송할 때는 JSON 구문을 이용해야 합니다.

3.3.1 파일 업로드

파일을 업로드할 때, 클라이언트는 MUST 미디어 엔드포인트가 존재하는지 확인해야 합니다. 미디어 엔드포인트가 없다면, Micropub 엔드포인트가 직접 파일을 받는다고 가정하고 요청을 바로 보낼 수 있습니다. Micropub 엔드포인트에 파일을 업로드하려면 전체 요청을 multipart/form-data 형식으로 작성하고 파일을 일반 속성으로 전송합니다.

예를 들어, 캡션이 포함된 사진을 업로드하려면 h, content, photo 세 부분으로 구성된 요청을 보냅니다.

multipart/form-data; boundary=553d9cee2030456a81931fb708ece92c

--553d9cee2030456a81931fb708ece92c
Content-Disposition: form-data; name="h"

entry
--553d9cee2030456a81931fb708ece92c
Content-Disposition: form-data; name="content"

Hello World!
--553d9cee2030456a81931fb708ece92c
Content-Disposition: form-data; name="photo"; filename="aaronpk.png"
Content-Type: image/png
Content-Transfer-Encoding: binary

... (binary data) ...
--553d9cee2030456a81931fb708ece92c--

파일 업로드를 허용하는 속성(예: photo 또는 video)에 대해, Micropub 엔드포인트는 MUST URL 값도 허용해야 하며, 직접 업로드된 파일처럼 취급해야 합니다. 엔드포인트는 MAY URL에서 파일을 다운로드하여 직접 업로드된 파일과 동일하게 저장할 수 있습니다. 예시:

h=entry&content=hello+world&photo=https%3A%2F%2Fphotos.example.com%2F592829482876343254.jpg

이 방식은 미디어 엔드포인트나 기타 외부 이미지를 참조하여 파일 업로드를 지원하기 위함입니다. 자세한 정보는 미디어 엔드포인트 절을 참고하세요.

3.3.2 JSON 구문

속성의 더 복잡한 값을 지원하려면, 파싱된 Microformats 2 JSON 형식으로 엔트리를 전송하여 게시물을 생성할 수 있습니다.

이 경우 파일 업로드는 불가능하며, 위에 설명한 대로 URL로만 파일을 참조할 수 있습니다.

JSON 형식으로 게시물을 생성할 때, 모든 값은 MUST 배열로 지정해야 합니다. 값이 하나만 있어도 마찬가지이며, 이는 Microformats 2 JSON 형식과 동일합니다. 이 요청은 application/json 컨텐트 타입으로 전송합니다.

mp-로 시작하는 속성은 예약된 속성과 같이 예약되어 동작함에 유의하세요.

POST /micropub HTTP/1.1
Host: aaronpk.example
Content-type: application/json

{
  "type": ["h-entry"],
  "properties": {
    "content": ["hello world"],
    "category": ["foo","bar"],
    "photo": ["https://photos.example.com/592829482876343254.jpg"]
  }
}

alt 텍스트가 포함된 사진 업로드

이미지에 alt 텍스트를 함께 업로드하려면 Microformats 2 구문을 사용하여 photo 속성에 이미지 URL과 alt 텍스트를 모두 지정할 수 있습니다. 단순한 URL 대신, 두 개의 속성(value: URL, alt: 텍스트)을 가지는 객체 형태로 값을 지정합니다. photo 값이 객체가 되어야 하므로, form-encoded나 multipart 요청에서는 사용할 수 없습니다. 대신 먼저 미디어 엔드포인트로 이미지를 업로드한 뒤, 아래와 같이 JSON 요청에서 URL을 참조해야 합니다.

POST /micropub HTTP/1.1
Host: aaronpk.example
Content-type: application/json

{
  "type": ["h-entry"],
  "properties": {
    "content": ["hello world"],
    "category": ["foo","bar"],
    "photo": [
      {
        "value": "https://photos.example.com/globe.gif",
        "alt": "Spinning globe animation"
      }
    ]
  }
}

3.3.3 중첩 Microformats 객체

가능하다면 중첩 Microformats 객체는 피하는 것이 좋으며, 객체를 URL로 참조하는 대안을 권장합니다. 가장 일반적인 예는 장소에 체크인하거나 사진에 인물 또는 장소를 태깅하는 등 venue용 h-card를 포함하는 경우입니다. 이런 경우, 필요하다면 먼저 객체를 생성한 뒤 URL로 참조하는 것이 더 낫습니다.

이 기법의 장점은, 생성된 각 객체가 자체 URL(각 데이터 조각마다 링크)을 갖도록 보장하며, 서버가 각 엔티티를 별도로 처리할 기회를 가집니다. 예를 들어 이미 존재하는 venue의 중복 생성을 피하고, 기존 venue 링크를 돌려주거나 새로운 데이터를 병합할 수 있습니다.

어떤 경우에는 중첩 객체에 URL이 없어도 괜찮습니다. 예를 들어 h-measure 값을 게시할 때, 그 자체로 URL이 필요하지 않으므로 중첩 Microformats 객체 구문을 사용해도 무방합니다.

중첩 객체는 요청이 JSON 형식으로 전송되어야 하며, form-encoding 구문으로는 일관되게 지원하지 않습니다.

아래 예시는 "weight" 측정 게시글을 새로운 h-entry로 생성하면서, h-measure 객체로 체중과 체지방 값을 기술합니다.

{
  "type": ["h-entry"],
  "properties": {
    "summary": [
      "Weighed 70.64 kg"
    ],
    "weight": [
      {
        "type": ["h-measure"],
        "properties": {
          "num": ["70.64"],
          "unit": ["kg"]
        }
      }
    ],
    "bodyfat": [
      {
        "type": ["h-measure"],
        "properties": {
          "num": ["19.83"],
          "unit": ["%"]
        }
      }
    ]
  }
}

3.3.4 양방향 텍스트

Micropub 요청의 자연어 값에는 MAY 양방향 텍스트가 포함될 수 있습니다. Micropub 텍스트 값의 기본 방향은 좌→우 (left-to-right)입니다. 각 자연어 값의 기본 방향은 아래와 같이 변경할 수 MAY 있습니다.

자연어 값의 양방향 텍스트를 지정할 때, 텍스트의 첫 강한 방향 문자를 통해 기본 방향이 올바르게 감지될 수 없는 경우 ([BIDI]), 게시 클라이언트는 적절한 유니코드 양방향 제어문자를 값 앞에 삽입하거나 HTML 값의 경우 HTML 방향 마크업을 사용해 기본 방향을 명시적으로 지정하는 것이 SHOULD 합니다.

Micropub 서버가 양방향 텍스트가 포함된 자연어 값을 받을 경우, 각 자연어 값의 기본 방향을 파악하기 위해 평문 값은 첫 강한 방향 문자를 검색하고, HTML 값은 가능하다면 방향 마크업을 사용하거나 그렇지 않으면 마크업 태그 밖의 첫 강한 방향 문자를 탐색해야 SHOULD 합니다. 이러한 자연어 값을 표시할 때 서버는 [BIDI] 알고리즘에 따라 콘텐츠 표시 방식이 결정되어야 하며, 표시 전 문자열에 추가 제어문자 또는 마크업을 감쌀 수 MUST 있습니다.

3.3.5 인식되지 않는 속성

요청에 서버가 인식하지 못하는 속성이 포함된 경우, 서버는 MUST 이를 무시하고, 인식되는 값만으로 게시물을 생성해야 합니다.

이렇게 하면 클라이언트는 해당 내용을 지원하는 서버엔 풍부한 콘텐츠를, 그렇지 않은 경우엔 대체 콘텐츠만 전송할 수 있습니다.

예를 들어, 클라이언트가 weight 속성에 h-measure 값을, summary에는 평문 요약을 넣어 게시물을 생성하면, 이 속성을 지원하지 않는 서버는 weight를 무시하고 summary만 사용하게 됩니다.

3.3.6 응답

게시물이 생성되면, Micropub 엔드포인트는 MUST HTTP 201 Created 또는 HTTP 202 Accepted 상태 코드를 반환해야 하며, Location 헤더에 생성된 게시물의 URL을 포함해야 합니다. [RFC2616]

HTTP/1.1 201 Created
Location: https://aaronpk.example/post/1000

엔드포인트가 요청을 즉시 처리하지 않고 비동기로 처리하기로 선택했다면, MUST HTTP 202 Accepted 상태 및 Location 헤더를 반환해야 하며, 오류 점검 및 유효성 검사는 HTTP 202 반환 전에 동기적으로 수행되어야 합니다. 클라이언트는 HTTP 202 응답을 받으면 지정된 URL에 객체가 곧 존재할 것이라 기대합니다.

타겟이 단축 URL을 제공하거나, 게시물이 다른 위치에 신디케이션된 경우, Micropub 엔드포인트는 HTTP Link 헤더와 적절한 "rel" 값을 사용하여 추가 URL을 MAY 반환할 수 있습니다. 예를 들면 게시물의 단축 URL은 다음과 같이 응답할 수 있습니다:

Link: <http://aaron.pk/xxxxx>; rel="shortlink"

Link: <https://myfavoritesocialnetwork.example/aaronpk/xxxxxx>; rel="syndication"

오류 응답

오류 발생 시 응답 방식에 대한 내용은 아래 "오류 응답" 절을 참고하세요.

3.4.1 교체

지정한 속성의 모든 값을 교체합니다. 속성이 없으면 새로 생성됩니다.

{
  "action": "update",
  "url": "https://aaronpk.example/post/100",
  "replace": {
    "content": ["hello moon"]
  }
}

이렇게 하면 게시물의 내용이 새 텍스트로 완전히 교체되며, 다른 기존 속성에는 영향이 없습니다.

3.4.2 추가

해당 속성에 기존 값이 있다면 그대로 두고, 새 값만 추가됩니다. 속성이 없다면 새로 생성됩니다.

신디케이션 URL 추가

사용 사례: 게시물이 발행된 후, 신디케이션 링크를 추가하는 경우. 예를 들어, 먼저 게시 후 MyFavoriteSocialNetwork 또는 Wikimedia로 신디케이션할 때, 사이트 측에서는 신디케이션 URL을 원본 게시물에 추가할 수 있어야 합니다.

신디케이션 URL 추가는 업데이트 요청에 하나 이상의 URL을 포함해 전송하면 됩니다.

{
  "action": "update",
  "url": "https://aaronpk.example/2014/06/01/9/indieweb",
  "add": {
    "syndication": ["http://web.archive.org/web/20040104110725/https://aaronpk.example/2014/06/01/9/indieweb"]
  }
}

태그 추가

사용 사례: 게시물 생성 후 태그를 추가하는 경우

category와 같이 여러 값을 가지는 속성의 경우, 추가할 값을 배열로 제공합니다.

{
  "action": "update",
  "url": "https://aaronpk.example/2014/06/01/9/indieweb",
  "add": {
    "category": ["micropub","indieweb"]
  }
}

3.4.3 삭제

해당 속성이 존재하면 삭제합니다. 지정한 속성을 완전히 삭제하게 됩니다.

{
  "action": "update",
  "url": "https://aaronpk.example/2014/06/01/9/indieweb",
  "delete": ["category"]
}

category와 같이 다중 값을 지닌 속성은, 각각의 값을 개별적으로 제거할 수 있습니다. 값이 남지 않으면 속성도 삭제됩니다.

{
  "action": "update",
  "url": "https://aaronpk.example/2014/06/01/9/indieweb",
  "delete": {
    "category": ["indieweb"]
  }
}

3.4.4 응답

서버는 업데이트 성공 시 HTTP 200, 201 또는 204로 응답해야 MUST 합니다. 업데이트로 게시물의 URL이 변경된 경우, 서버는 HTTP 201로 새 URL을 Location 헤더에 포함하여 반환해야 MUST 하며, 그 외에는 응답 본문 유무에 따라 200 또는 204로 응답합니다. 응답 본문은 필수가 아니지만, MAY 어떤 변경이 있었는지 설명하는 JSON 객체를 포함할 수 있습니다.

3.5.1 응답

서버는 삭제 또는 복구가 성공하면 HTTP 200, 201 또는 204로 응답해야 MUST 합니다. 복구 작업으로 게시물의 URL이 변경된 경우 반드시 HTTP 201로 새 URL을 Location 헤더에 포함하여 반환해야 하며, 그렇지 않으면 응답 본문 유무에 따라 200 또는 204로 응답해야 합니다. 응답 본문은 필수가 아니지만, MAY 변경된 내용을 설명하는 JSON 객체를 포함할 수 있습니다.

3.6.1 탐색

Micropub 엔드포인트가 미디어 엔드포인트를 지원함을 알리기 위해, 서버는 MUST Micropub configuration query 응답에 media-endpoint라는 키에 미디어 엔드포인트의 전체 URL을 포함해야 합니다. 클라이언트는 미디어 엔드포인트가 반드시 Micropub 엔드포인트와 동일 도메인에 있음을 MUST NOT 가정해서는 안 됩니다.

GET /micropub?q=config
Authorization: Bearer xxxxxxxxx

{
  "media-endpoint": "https://media.example.com/micropub"
}

3.6.2 인증

미디어 엔드포인트는 Micropub 엔드포인트와 동일한 액세스 토큰을 MUST 허용해야 합니다.

3.6.3 요청

클라이언트가 미디어 엔드포인트에 파일을 업로드하려면, file이라는 이름의 파트 하나를 포함하는 multipart/form-data 요청을 전송해야 합니다. 미디어 엔드포인트는 MAY 클라이언트가 전송하는 파일명을 무시할 수 있습니다.

multipart/form-data; boundary=553d9cee2030456a81931fb708ece92c

--553d9cee2030456a81931fb708ece92c
Content-Disposition: form-data; name="file"; filename="sunset.jpg"
Content-Type: image/jpeg
Content-Transfer-Encoding: binary

... (binary data) ...
--553d9cee2030456a81931fb708ece92c--

3.6.4 응답

미디어 엔드포인트는 파일 업로드를 처리하여 원하는 백엔드에 저장하고, 파일에 대한 URL을 생성합니다. 이 URL은 UUID를 경로나 파일 이름에 사용하여 추측할 수 없는 값으로 하는 것이 SHOULD 합니다. 요청이 성공하면, 엔드포인트는 생성된 파일의 URL을 HTTP Location 헤더에 포함하고 HTTP 201 Created로 응답해야 MUST 하며, 응답 본문은 별도로 정의되지 않습니다.

HTTP/1.1 201 Created
Location: https://media.example.com/file/ff176c461dd111e6b6ba3e1d05defe78.jpg

Micropub 클라이언트는 이 URL을 예를 들어 Micropub 요청의 "photo" 속성 값으로 사용할 수 있습니다.

미디어 엔드포인트는 특정 시간 내에 Micropub 요청에서 사용되지 않은 업로드 파일을 주기적으로 삭제할 수 MAY 있습니다.

3.7.1 구성

사용자가 Micropub 클라이언트에 처음 로그인하면, 클라이언트는 사용자의 엔드포인트에 대한 몇 가지 초기 정보를 확인하고자 합니다. 클라이언트는 q=config 쿼리를 사용하여 초기 구성 정보를 요청하는 것이 SHOULD 합니다.

서버는 구성 응답에 다음 정보를 SHOULD 포함해야 합니다.

• 지원하는 신디케이션 엔드포인트 목록은 syndicate-to라는 속성에 포함(신디케이션 대상 구조 참고)
• 지원하는 경우 media-endpoint라는 속성에 미디어 엔드포인트 포함

GET /micropub?q=config
Authorization: Bearer xxxxxxxxx
Accept: application/json

HTTP/1.1 200 OK
Content-type: application/json

{
  "media-endpoint": "https://media.example.com/micropub",
  "syndicate-to": [
    {
      "uid": "https://myfavoritesocialnetwork.example/aaronpk",
      "name": "aaronpk on myfavoritesocialnetwork",
      "service": {
        "name": "My Favorite Social Network",
        "url": "https://myfavoritesocialnetwork.example/",
        "photo": "https://myfavoritesocialnetwork.example/img/icon.png"
      },
      "user": {
        "name": "aaronpk",
        "url": "https://myfavoritesocialnetwork.example/aaronpk",
        "photo": "https://myfavoritesocialnetwork.example/aaronpk/photo.jpg"
      }
    }
  ]
}

서버는 SHOULD 구성 쿼리를 지원하며, 서버와 관련된 모든 속성을 반환해야 합니다. 해당 속성이 없으면 응답은 빈 JSON 객체 {} 여야 합니다.

클라이언트는 예기치 않은 응답을 빈 응답과 마찬가지로 처리해야 SHOULD 하며, 이를 통해 해당 쿼리를 지원하지 않는 서버로부터 예기치 않은 응답(예: HTTP 400)도 대응할 수 있습니다.

3.7.2 원본 콘텐츠

Micropub 클라이언트는 엔드포인트에 특정 게시물의 일부 속성만 반환하도록 쿼리할 수 있습니다. 이렇게 하면 원하는 속성만 요청하여, 예를 들어 게시물에 태그 추가와 같은 인터페이스를 구현할 수 있습니다.

게시물 수정 기능을 지원하는 서버는 MUST source content 쿼리를 지원해야 합니다.

쿼리하려면, Micropub 엔드포인트에 GET 요청을 보내고 q 파라미터에 source를, url 파라미터에 게시물 URL을 지정합니다. properties 키에 원하는 속성명을 하나 이상 포함할 수 있으며, 둘 이상일 경우 [HTML5] URL 인코딩 방식에 따라 배열 대괄호 표기법을 사용합니다.

엔드포인트는 [microformats2-parsing] [JSON] 형식으로, 요청된 속성명이 키, 값은 배열로 이루어진 properties 객체로 응답해야 MUST 합니다. 속성이 지정되지 않으면, 모든 속성과 게시물 어휘를 나타내는 type 속성도 반드시 포함해야 합니다.

GET /micropub?q=source&properties[]=published&properties[]=category&url=https://aaronpk.example/post/1000
Authorization: Bearer xxxxxxxxx
Accept: application/json

HTTP/1.1 200 OK
Content-type: application/json

{
  "properties": {
    "published": ["2016-02-21T12:50:53-08:00"],
    "category": [
      "foo", 
      "bar"
    ]
  }
}

GET /micropub?q=source&url=https://aaronpk.example/post/1000
Authorization: Bearer xxxxxxxxx
Accept: application/json

HTTP/1.1 200 OK
Content-type: application/json

{
  "type": ["h-entry"],
  "properties": {
    "published": ["2016-02-21T12:50:53-08:00"],
    "content": ["Hello World"],
    "category": [
      "foo", 
      "bar"
    ]
  }
}

HTML 콘텐츠

게시물 원본이 HTML로 작성된 경우, 엔드포인트는 content 속성을 html 속성을 포함하는 객체로 반환해야 MUST 합니다. 그 외의 경우 값은 단순 문자열이어야 하며, 클라이언트는 이를 일반 텍스트로 처리합니다. 이는 [microformats2-parsing]의 속성값 처리와 동일합니다.

아래는 HTML로 작성된 게시물 내용을 쿼리하는 예시입니다.

GET /micropub?q=source&properties=content&url=https://aaronpk.example/post/1000
Authorization: Bearer xxxxxxxxx
Accept: application/json

HTTP/1.1 200 OK
Content-type: application/json

{
  "properties": {
    "content": [
      {
        "html": "<b>Hello</b> <i>World</i>"
      }
    ]
  }
}

3.7.3 신디케이션 대상

지원하는 신디케이션 대상 목록을 반환하려면, q 파라미터에 syndicate-to를 지정하면 됩니다.

GET /micropub?q=syndicate-to

엔드포인트는 응답을 [JSON] 형식으로 해야 하며, syndicate-to라는 키 아래 지원 대상 설명 객체들을 배열로 반환해야 MUST 합니다. 대상이 없다면, syndicate-to 값은 빈 배열 []이어야 SHOULD 합니다.

최소한 각 신디케이션 대상에는 MUST uid와 사람이 읽을 수 있는 name 속성이 포함되어야 합니다. uid는 Micropub 엔드포인트별로 유일한 식별자이며, 사용자에게 표시되는 값은 아닙니다. name은 게시 인터페이스에서 사용자에게 표시되는 설명용 값이어야 합니다.

신디케이션 대상은 MAY 서비스 또는 대상 사용자 계정에 대한 세부 정보를 service와 user 속성에 추가로 포함할 수 있습니다. 두 객체 모두 사용자에게 표시할 name 속성이 필수이며, MAY url과 photo도 가질 수 있습니다. 클라이언트는 이들 이름, 사진을 UI에서 활용할 수 있습니다.

GET /micropub?q=syndicate-to
Authorization: Bearer xxxxxxxxx
Accept: application/json

HTTP/1.1 200 OK
Content-type: application/json

{
  "syndicate-to": [
    {
      "uid": "https://archive.org/",
      "name": "archive.org"
    },
    {
      "uid": "https://wikimedia.org/",
      "name": "WikiMedia"
    },
    {
      "uid": "https://myfavoritesocialnetwork.example/aaronpk",
      "name": "aaronpk on myfavoritesocialnetwork",
      "service": {
        "name": "My Favorite Social Network",
        "url": "https://myfavoritesocialnetwork.example/",
        "photo": "https://myfavoritesocialnetwork.example/img/icon.png"
      },
      "user": {
        "name": "aaronpk",
        "url": "https://myfavoritesocialnetwork.example/aaronpk",
        "photo": "https://myfavoritesocialnetwork.example/aaronpk/photo.jpg"
      }
    }
  ]
}

최소한 각 신디케이션 대상에는 MUST uid와 name 속성이 있어야 합니다. uid는 클라이언트에 불투명하며, Micropub 요청에서 신디케이션 대상을 지정할 때 이 값을 사용합니다. name은 사용자가 볼 수 있도록 표시해야 하며, 예를 들면 같은 서비스에 대상이 둘 이상일 때 혼동이 없도록 반드시 구별되어야 합니다.

Micropub 서버는 MAY 신디케이션 서비스와 사용자 계정에 관한 추가 정보도 포함할 수 있으며, 추가 속성 service와 user는 name(사람이 읽을 수 있는 이름), url과 photo(URL 형태) 속성을 모두 가질 수 있습니다.

클라이언트는 서비스/사용자 속성을 활용하여 신디케이션 UI에 사진이나 이름을 표시할 수 있습니다.

신디케이션 기능 지원 서버는 syndicate-to 쿼리도 SHOULD 지원해야 합니다.

3.7.4 쿼리 확장

쿼리 기능을 확장하려는 클라이언트와 서버는 indieweb.org/Micropub-extensions에서 아이디어 토론 및 구현 예시를 문서화하는 것이 권장됩니다.