api-blueprint 🚀 - 외부 자산

저는 이 기능에 관심이 있으며 나중에라도 빨리 추가되기를 바랍니다.

우리의 특정 사용 사례는 요청 및 응답 본문이 Apache Avro에 의해 생성된 이진 구조인 API를 문서화하는 것입니다. 이러한 요청/응답의 경우 "스키마"가 Avro 스키마 정의 파일 또는 해당 Avro 스키마를 설명하는 생성된 HTML 문서에 대한 링크가 될 수 있기를 바랍니다. 다음과 같이 보일 수 있습니다.

## POST /myresource
Creates a new myresource.

+ Request (application/vnd.example.myresource+avro)
    + Schema:
        [MyResource.avsc](http://docs.example.com/avro/myresource.avsc)
+ Response 201 (application/vnd.example.myresource+avro)
    + Schema:
        [MyResource.avsc](http://docs.example.com/avro/myresource.avsc)

davidmc24 에 2013년 10월 21일

👍5

:+1:

mhurne 에 2013년 10월 21일

@mhurne @davidmc24 AST에서 이 기능의 표현에 대해 생각해 보셨습니까? AST에서 하이퍼링크를 보고 싶습니까? 아니면 청사진 파서가 대상 URL을 가져오고 해당 콘텐츠를 AST에 포함할 수 있어야 합니까?

netmilk 에 2013년 10월 21일

내 예상은 AST에 해당 하이퍼링크의 내용이 아니라 하이퍼링크가 포함될 것이라는 것입니다. 예를 들어 HTML 문서에서 링크를 생성할 수 있도록 AST가 직접 콘텐츠가 아닌 하이퍼링크임을 "알고" 있으면 유용할 수 있습니다.

API에서 스키마를 외부화하기로 선택한 경우 스키마가 너무 커서 API 문서에서 인라인하기에 적합하지 않거나 스키마가 여러 API에서 사용되며 자체적으로 신뢰할 수 있는 문서가 있거나 schema는 임베딩에 적합하지 않은 형식입니다. 이러한 예는 스키마에 따라 다르지만 비슷한 이유가 다른 페이로드 유형에도 적용될 것으로 예상합니다.

davidmc24 에 2013년 10월 21일

@davidmc24

나는 그것을 좋아한다. 하이퍼링크일 경우 파서에서 구현하기가 상당히 쉬울 것입니다.

그러나 더 큰 과제는 AST 및 해당 미디어 유형에 필요한 변경과 함께 제공됩니다.

아마도 다음과 같이 될 것입니다.

{
  "name": "<name>",
  "description": "<description>",
  "headers": {
    "<header>": {
      "value": "<header value>"
    }
  },
  "body": {
    "content": "<body>",
    "href": "<uri>"
  },
  "schema": {
    "content": "<schema>",
    "href": "<uri>"
  }
}

zdne 에 2013년 10월 22일

네, 바로 제가 고려하고 있던 AST입니다.

davidmc24 에 2013년 10월 22일

추가로 Drafter apiaryio/snowcrash#57에 의해 외부 자산이 삽입될(단지 참조 링크가 아닌) 추가 구문을 추가합니다.

:[file.json](path/to/file.json)

또는

=[file.json](path/to/file.json)

또는 Markkown _암시적 링크 이름_ 사용:

:[path/to/file.json]()

또는

=[path/to/file.json]()

zdne 에 2014년 01월 31일

👍3

안녕하십니까,
다음은 외부 링크를 사용하는 또 다른 사용 사례입니다. API의 속성 정의/설명을 모든 문서에서 사용되는 마스터 용어집의 해당 정의에 연결하고 싶습니다. 이것이 모든 문서를 최신 상태로 동기화할 수 있는 가능성을 열어준다고 생각합니다. 그렇지 않으면 API 문서를 업데이트해야 합니다. 정의가 동기화되지 않을 여지를 남겨둡니다.

angie2014 에 2014년 05월 28일

Markdown은 대부분 호환되는 확장의 불편할 정도로 느슨하게 결합된 제품군이므로 확실하지 않지만 링크와 같은 구문이 실제로 "참조가 아닌 포함"을 의미하는 경우는 이미지 구문( ! sigil 사용)입니다. : ![Alt text](/path/to/image.jpg "Optional Title") , 이것은 Gruber의 원래 사양 의 일부입니다. 무엇보다 Z의 제안은 이 구조(파일 이름이 잘못된 위치에 있음)를 위반합니다. 준수하는 것이 더 낫지 않습니까? 그렇지 않으면 기존 구문에 새 sigil을 사용하십시오.

jrep 에 2014년 05월 30일

좋은 지적 @jrep !

준수하는 것이 더 낫지 않습니까? 그렇지 않으면 기존 구문에 새 sigil을 사용하십시오.

그것이 제 목표입니다.

Gruber 에 따르면 다음과 같은 목표를 달성해야 합니다.

[label](path/to/image.png)

[alt text][label2]
[label2]: path/to/image.png

[label3][]
[label3]: path/to/image.png

여기서 label , alt text 및 label3 는 이론상 존재하지 않지만 렌더링 후에 요소가 표시되지 않습니다.

나는 나의 요점을 추측한다.

=[path/to/file.json]()

해야한다

=[path/to/file.json][]

여기서 레이블은 실제 URL이므로 적절한 전체 정의(마크다운이 올바르게 렌더링됨)는 다음과 같습니다.

=[path/to/file.json][]
[path/to/file.json]: path/to/file.json

이제 다음과 같이 작성하는 것은 분명히 지루할 것입니다.

[path/to/file.json]: path/to/file.json

질문은 – 이(레이블 정의)가 파서에 의해 암시적으로 가정되어야 합니까? 아니면 청사진 작성자에게 [alt text](URL) 구문을 사용하도록 요청해야 합니까?

zdne 에 2014년 06월 02일

링크가 사람이 읽을 수 있도록 실제로 _자산이 무엇인지 설명하기 위해 alt/label 부분을 사용할 수 없었습니까? =[file.json](path/to/file.json) 와 같은 것을 작성하는 것은 불필요하게 지루한 것처럼 보이지만 =[Schema for notes](path/to/file.json) 는 괜찮은 것 같습니다. 청사진 작성자가 청사진을 독자에게 덜 비밀스럽게 만들도록 권장합니다. 실제로 자산이 누락되거나 정확히 연결된 것이 명확하지 않을 수 있습니다. alt 속성은 정확히 이 경우를 위해 발명된 것 같습니다.

누군가 이것을 우회하고 이런 식으로 자산을 설명하는 모범 사례를 무시하려는 경우, 그녀는 항상 거기에 더미 텍스트를 넣을 수 있습니다(예: 이미 언급된 file.json ).

= 구문을 예제로 사용했는데 ! 에도 동일하게 적용됩니다.

honzajavorek 에 2014년 06월 02일

사용된 구문(직접 링크, 명시적 또는 암시적 레이블)에 관계없이 추가 기호로 마크다운을 지원해야 한다고 생각합니다.

우리가 이에 동의한다면 다음 두 가지 질문만 남습니다.

어떤 인장을 사용할 것인가
예제/튜토리얼에서 사용할 스타일

내 의견으로는 Schema for notes 와 같은 레이블이 있습니다.

=[Schema for notes](path/to/file.json)

대부분의 경우 Notes 리소스의 스키마 섹션에서 사용하기 때문에 중복입니다...

예:

# Notes [/notes]
## GET 
+ Response 200
    + Body
         ...
    + Schema
        =[Schema for Notes](path/to/file.json)

생각?

zdne 에 2014년 06월 02일

저는 모든 표준 변형을 지원하는 데 찬성하지만 다음과 같습니다.

=[경로/to/file.json][]
[경로/to/file.json]: 경로/to/file.json

... 내가 Gruber의 정의를 이해하는 방법이 아닙니다. 오히려 나는 honzajavorek에 동의합니다. 첫 번째 []의 내용은 링크 텍스트의 중복되고 귀찮은 복제가 아니라 어떤 면에서 사람이 읽을 수 있는 태그입니다. 따라서 거기에 경로를 포함하는 것이 구문적으로 유효한 것처럼 보이지만 (a) 이상하고 (b) 도움이 되지 않습니다.

의도가 "새로운 서명이 있는 모든 Gruber-유효한 링크 형식"이라면 나는 그 의미를 좋아하지만 덜 놀라운 예(혼자자보렉과 내가 제안한 종류)를 제안합니다.

jrep 에 2014년 06월 03일

@jrep @honzajavorek 동의합니다.

zdne 에 2014년 06월 03일

이미지나 링크에 대한 자산 포함을 기존 패턴과 비교하는 것은 어렵다고 생각합니다. 사실 이 둘의 조합 아닌가?

이미지 구문 유추의 문제는 이미지의 세계에서 대체 텍스트가 중요하고 일반적으로 주어진 컨텍스트에서 중복되지 않으며 아무도 실제로 ![img.jpg](/path/to/img.jpg) 쓰고 싶어하지 않는다는 것입니다. 콘텐츠 관리 시스템과 "게으른" 사람들은 이것을 합니다. 대체 텍스트를 요구하는 것은 좋은 습관을 가르치는 것입니다.

그러나 자산에 반드시 대체 텍스트가 필요한 것은 아닙니다. 사실입니다. @zdne이 언급했듯이 여기에서 무슨 일이 일어나고 있는지 완전히 명확하게 알 수 있는 컨텍스트에서 항상 사용됩니다. 나는 그것에 동의합니다. 문제는 내가 생각할 수 있는 유일한 비유는 레이블이 없는 링크라는 것입니다.

[Google](http://www.google.com) 대...

<http://www.google.com> ( 그루버 )
http://www.google.com (오늘의 마크다운 현실, 추측)

하이브리드가 필요한 경우 "이미지에 대한 자동 링크 구문"이라고 부르고 가능한 한 Gruber를 준수하기를 원하면 다음과 같은 것을 원합니다.

=[Alternative text about assets](/dev/null) ← 모든 사람이 이에 대해 잘 알고 있습니다. 예를 들어 설명해야 합니다.
=[Alternative text about assets][id] ← 동일한 자산을 여러 위치에 포함하는 경우
=</dev/null> or <=/dev/null> ← autolink 구문(_... 이미지의 경우 autolink 구문은 어떻게 생겼을까요?_), Gruber의 autolink 버전은 아무도 모릅니다. < s 및 > s), 그러나 실제로 대체 텍스트가 필요하지 않고 이에 짜증이 나는 경우 사람들은 이것을 사용하는 방법을 배울 수 있습니다.

다시 한 번 예로 = 를 사용합니다. 제 생각에는 이것이 가장 읽기 쉽고 적어도 Gruber 같은 솔루션이 될 것입니다. 예를 들어, 나는 고려

[label3][]
[label3]: path/to/image.png

기존 Markdown 사용의 현실을 따르지 않고 독자인 저에게는 다소 비밀스럽습니다. 나는 그런 가능성에 대해서도 몰랐습니다. 페어링은 두 번째 브래킷에 의해 수행되어야한다고 생각했습니다. (그러나 이 마지막 단락은 매우 주관적이라는 것을 충분히 알고 있습니다.)

honzajavorek 에 2014년 06월 03일

@zdne : = 는 괜찮아 보입니다.

@zdne : 가장 가능성이 높은 텍스트 =[IN HERE](schema.json) 는 제가 생각할 수 있는 블루프린트 용도에 중복된다는 점을 인정합니다. 여기에서는 브레인스토밍만 하면 되지만 문법을 단순화하기 위해 그 중복성을 활용하면 어떨까요? 즉, 교체

# Notes [/notes]
## GET 
+ Response 200
    + Body
         ...
    + Schema
        =[Schema for Notes](path/to/file.json)

~와 함께

# Notes [/notes]
## GET 
+ Response 200
    + Body
         ...
    + =[Schema for Notes](path/to/file.json)

@honzajavorek : 실제로 Blueprint가 해당 위치에서 "/dev/null" 문자열을 허용/명령하도록 제안하고 있습니까? 아니면 그냥 자리 표시자였습니까?

저는 "참조 링크"도 사용하지 않지만, 블루프린트가 이를 전달하는 것을 반대하지는 않습니다.

jrep 에 2014년 06월 03일

@jrep /dev/null 자리 표시자로 사용했습니다. :)

섹션 헤더에서 직접 링크를 사용하는 것은 실제로 전혀 나빠 보이지 않습니다! 물론, 첫눈에 그런 것의 단점이 무엇인지 잘 생각하지 못했지만... 첫눈에는 매력적으로 보입니다.

honzajavorek 에 2014년 06월 03일

@jrep 좋아요.

더 나아가

# Notes [/notes]
## GET 
+ Response 200
    + =[Body](path/to/body.json)
    + =[Schema](path/to/schema.json)

zdne 에 2014년 06월 04일

파일을 별도의 파일로 분할한 다음 가져오는 기능은 장황한 API에 매우 유용합니다.

중간에 나는 grunt로 청사진 프로젝트를 관리합니다. 나는 grunt-import를 사용하고 내 index.source.apib 파일은 대부분 <strong i="7">@import</strong> "/include/section.apib";

그런 다음 내가 하는 모든 것은 grunt watch 하고 파일을 저장하자마자 grunt가 내 index.source.apib 파일을 'index.apib'로 다시 컴파일합니다. 이 파일은 역시 aglio가 감시하고 있어 브라우저를 다음으로 새로고침합니다. 실시간으로 렌더링을 보여주세요.

설정하는 데 5분이 걸리지만 삶이 훨씬 더 멋집니다! :+1:

alexborisov 에 2014년 08월 30일

@alexborisov 꽤 깔끔합니다! 공유해 주셔서 감사합니다. 내가 말했듯이 (다른 곳에서) – 우리는 결국 이것을 처리해야 하는 파서 하네스 도구에 대한 작업을 시작했습니다.

또한 그 가치를 위해 여러 청사진을 하나로 구성하고 Apiary 클라이언트 gem https://gist.github.com/danvine/11087404를 사용하여 게시하는 스크립트가

zdne 에 2014년 09월 01일

@alexborisov , 정말 똑똑한 해결 방법입니다! 당신(또는 이 문제를 보고 있는 사람)이 grunt-import에 대응하는 Gulp가 있는지 알고 있습니까? 모든 대상 JS 및 html 문서를 찾았습니다.

skawaguchi 에 2014년 11월 24일

@skawaguchi gulp -file-include 를 사용하고 json을 관찰하고 API를 빌드하는 gulp 작업을 만들 수 있습니다. 유일한 단점은 api.md를 생성하기 위해 api.source.md가 있어야 하지만 IMO는 지불해야 하는 비용이 적다는 것입니다.

ghost 에 2015년 02월 24일

또한 @jamesramsay 의 Hercule – https://github.com/jamesramsay/hercule을 체크아웃할 가치가 있는 것

zdne 에 2015년 02월 25일

언급해 주셔서 감사합니다 @zdne . API 문서를 작성할 때도 비슷한 문제가 있었고 지난 3개월 동안 내부적으로 Hercule을 사용해 왔습니다.

Hercule은 포함을 위해 간단한 {{filename.md}} 패턴을 사용합니다.

거의 동일한 리소스를 가진 다양한 유형의 API 소비자를 위한 여러 API 컨텍스트가 있으며 서로 다른 문서 간의 중복을 줄이기 위해 노력했습니다. 따라서 다음도 지원하도록 이 구문을 확장했습니다.

{{entity.json links:role-links.json}}

{
  "id": 123,
  "name": "example",
  "links": {
    {{links}}
  }
}

{{links}} 자리 표시자는 상위 파일 중 하나로 지정된 대상 파일을 가질 수 있습니다. 이것이 거의 동일한 대규모 스키마에 유용하다는 것을 알았습니다.

jamesramsay 에 2015년 02월 26일

@jamesramsay

Markdown 고유의 [<placeholder>](link) 대신 {{link}} 구문을 사용하는 이유가 궁금합니다. 위에서 논의한 바와 같이. 예를 들어:

=[gist](gist.apib)

또는

:[gist](gist.apib)

비슷하게 작동하고 마크다운으로 합리적으로 렌더링되므로 링크를 탐색할 수 있으며 `[placeholder] 링크 옵션과 함께 [placeholder][] 와 같은 훨씬 더 풍부한 구문을 사용할 수 있습니다...

zdne 에 2015년 02월 27일

@zdne 정말 좋은 제안입니다! 6개월 전에 이 스레드를 보지 못한 것이 아쉽습니다.

{{link}} 구문은 MultiMarkdown 4의 transclusion 구문을 기반으로 했습니다. 그것은 트릭을했고 나는 새로운 구문을 발명하지 않았습니다.

당시 나는 Marked 앱( <<[link] )과 몇 가지 다른 Markdown 컴파일러도 살펴보았습니다.

Github에서 소스 문서를 볼 때 링크를 클릭할 수 있다는 이점과 Markdown의 느낌과의 일관성이 향상되어 :[gist](gist.apib) 를 사용하도록 hercule을 업데이트했습니다. 누군가가 회전을 원하면 NPM에 있습니다.

jamesramsay 에 2015년 03월 04일

안녕하세요 여러분, 저는 내부 프로젝트에 aglio 와 함께 API Blueprint를 사용하고 있습니다. API Blueprint는 현재 포함하는 파일을 지원하지 않기 때문에 aglio는  구문으로 하나를 구현합니다. 이 기능 덕분에 요청/응답을 분할할 수 있습니다. API 문서의 JSON 데이터는 명확하지만, 분리된 JSON 데이터 파일을 구성할 때 동일한 부분을 재사용할 적절한 방법이 여전히 부족하다는 것을 알았습니다. 예를 들어 user_model.json .

{
    "username": "alice",
    "comments": [
        {
            "id": 1,
            "content": "hello"
        }
    ]
}

및 comment_model.json :

{
    "id": 1,
    "content": "hello"
}

user_model.json 의 주석 부분은 항상 comment_model.json 와 같아야 합니다. JSON 파일이 서로 포함되도록 하는 메커니즘이 있다면 일관성을 유지하기가 매우 쉬울 것입니다. commend 모델이 변경된 경우 모든 곳에서 변경할 필요가 없습니다.

나는 한동안 그것을 고려하고 여기에 내 노력을 포함하여 JSON 파일을 지원하는 구문을 만들려고합니다.
Python 구현이 포함된 sytanx 포함: https://github.com/reorx/json_include

이전의 경우 구문은 다음과 같습니다.

{
    "username": "alice",
    "comments": [
        {
            "...": "include(commend_model.json)"
        }
    ]
}

{ "...": "include(commend_model.json)"} 를 사용하여 commend_model.json 파일에 대한 포함을 나타냅니다.

API Blueprint에 대한 특별한 경우가 아니라 JSON 자체를 포함 기능으로 생각하려고 하는 다소 일반적인 것입니다. API Blueprint에서도 사용할 수 있다고 생각합니다.

살펴보고 몇 가지 제안을 하십시오. 현재 이 json-include 는 내 프로젝트 중 일부에서 잘 작동하고 있습니다. 혼자가 좋고 의미가 있는지 여부를 결정할 수 없기 때문에 이에 대한 모든 생각은 매우 감사할 것입니다. )

reorx 에 2015년 04월 28일

안녕하세요 @reorx입니다 ! 아이디어를 공유해 주셔서 감사합니다. 최근 우리는 API Blueprint에서 데이터를 설명하는 구문인 MSON (베타)을 출시했습니다. 아이디어는 데이터를 한 번 설명한 다음 다른 형식으로 직렬화를 요청하는 것입니다.

귀하의 예를 사용하면 다음과 같이 작동합니다.

# Data Structures

## User 
- username: alice
- comments (array[Comment])

## Comment
- id: 1
- content: hello

그런 다음 JSON으로 렌더링하도록 요청할 수 있습니다.

# Resource [/r]
## Retrieve [GET]
+ Response (application/json)
    + Attributes (User)

어떻게 생각하나요? 도움이 될까요?

zdne 에 2015년 04월 28일

이 기능이 파이프라인의 어디에나 있습니까? 그것은 우리에게 매우 좋을 것입니다.
Blueprint를 사용하여 메서드를 설명하지만 JSON 스키마는 별도로 호스팅됩니다. 현재 request/response 요소에서 지원되지 않기 때문에 메서드 설명에 링크로 스키마를 포함해야 합니다.
실제로 가장 이상적인 것은 request/response 요소 아래에 있는 링크를 사용하여 JSON 스키마 웹 페이지를 "포함"할 수 있지만 문서 페이지가 로드될 때 수백 개의 포함을 수행하지 않도록 느리게 로드되어야 하는 경우입니다.

jonathancrosmer 에 2015년 08월 20일

요청/응답 본문 예제 및 정의 스키마 파일에 대한 외부 참조를 포함할 수 없다는 사실은 Blueprint가 다른 API 정의 언어와 관련하여 _매우_ 큰 단점 중 하나라고 생각합니다.

mariusor 에 2015년 11월 17일

+1

moon0326 에 2015년 11월 21일

@jonathancrosmer @lpbm @moon0326

특히 https://github.com/jamesramsay/hercule 확인

https://github.com/jamesramsay/hercule/blob/master/examples/api-blueprint/gist-fox.apib

그리고

https://github.com/jamesramsay/hercule/blob/master/examples/api-blueprint/blueprint/gists.md

이것이 당신에게 효과가 있습니까?

zdne 에 2015년 11월 24일

@zdne 팔로우 하지 않습니다.

이 두 가지 예는 별로 보여주지 않습니다. 내가 무엇을보고 있습니까?

moon0326 에 2015년 11월 24일

@zdne : 예, .md/.apib 또는 xml, json 등 모든 유형의 외부 리소스를 포함할 수 있는 한 좋습니다.

그것은 양봉장에서 구현할 것입니까, 아니면 귀하의 메시지가 양봉장에 커밋하기 전에 hercule를 사용하도록 조언하는 것입니까?

mariusor 에 2015년 11월 24일

예전에 청사진을 여러 파일로 분할하고 외부 자산을 사용하기 위한 솔루션 목록을 준비했습니다. https://gist.github.com/zdne/137396a1c2d45f75b306

@jamesramsay 는 청사진을 여러 부분으로 분할하는 데 사용하고 싶은 구문을 구현하는 멋진 Hercule 도구를

외부 자산의 경우. Hercule도 거기에서 작동하지만 이것이 최종 구문이어야 하고 특히 MSON 의 프리즘을 통해 JSON blob 내부에서 사용을 제안해야 하는지 확실하지 않습니다.

그럼에도 불구하고 Apiary 내부 편집에 의존하지 않는다면 오늘 Hercule를 사용하여 이 기능의 대부분을 얻을 수 있습니다.

Apiary가 구현할 것입니까?

우리는 :[](url) 구문을 기반으로 일부 transclusion을 구현하고 싶습니다. 그렇습니다. 여기서 캐치는 "파일 시스템"의 Apiary 편집기 및 구현입니다. 그때까지는 Hercule을 사용하고 연결된 파일을 Apiary에 푸시해야 합니다.

이것이 명확해 졌습니까?

zdne 에 2015년 11월 25일

👍1

여기서 캐치는 "파일 시스템"의 Apiary 편집기 및 구현입니다.

URL을 사용하여 이를 우회할 수 있습니까?

mariusor 에 2015년 11월 25일

문서를 가져오기 위해서는 가능하지만 편집용은 아닙니다.

zdne 에 2015년 11월 25일

현재 Apiary에 연결된 git 저장소에 Apiary 청사진이 저장되어 있습니다. 청사진에는 JSON 스키마를 호스팅하는 내부 서버에 대한 많은 링크가 있습니다.
이 솔루션을 사용하면 원본 Markdown 파일이 있고 Git 후크 또는 무언가를 사용하여 트랜스클루전을 실행하고 결과를 동기화된 청사진으로 커밋할 수 있다고 가정합니다. 작동할 수 있을 것 같습니다. 트랜스클루전 프로세스를 설정하는 데 약간의 번거로움이 있지만 작동하면 매끄럽게 될 것이므로 살펴보겠습니다. 감사 해요!

jonathancrosmer 에 2015년 11월 25일

@lpbm Hercule은 로컬 파일(상대 파일 경로)과 원격 파일(URL)

@jonathancrosmer spot on - 내부 CI 환경에서 Jenkins를 사용하여 유사한 작업을 수행합니다. Adslot에서는 커밋이 분기에 푸시될 때마다 단위 테스트와 함께 Hercule로 API Blueprint를 컴파일한 다음 drredd에 전달합니다. 모두 통과하는 경우 배포 작업의 일부로 선택적으로 Apiary에 푸시할 수 있습니다. 우리는 원래 API 문서가 변경되자마자 Apiary에 직접 푸시했지만 기능 스위치 등으로 더 큰 릴리스를 작업할 때 때때로 문제가 발생한다는 것을 발견하여 이제 애플리케이션과 함께 배포합니다.

jamesramsay 에 2015년 11월 25일

일반 URI를 지정하도록 허용하는 것은 어떻습니까? 렌더러는 URI를 링크로 렌더링할지 아니면 문서 출력에 해당 콘텐츠를 포함할지 결정할 수 있습니다. 이것은 또한 우리가 다른 Markdown 풍미를 처리해야 하는 수고를 덜어줍니다.

bartfeenstra 에 2016년 05월 20일

일반 URI를 지정하도록 허용하는 것은 어떻습니까?

그래야 한다. [label](URI) 는 트랜스클루션에 사용되어야 하며 잘 렌더링되어야 합니다. 차이점은 transclustion 도구의 경우 표시해야 하므로 :[label](URI)

zdne 에 2016년 06월 09일

안녕하세요,

이에 대한 소식이 있습니까?
스키마와 예제는 API 문서의 본문과 분리되어야 서버 및/또는 클라이언트에서 유효성 검사 및 단위 테스트에 사용할 수 있다고 생각합니다. 링크는 괜찮습니다.

건배,

타마스

smil2k 에 2017년 12월 11일

안녕하세요 여러분, 늦게 와서 오래된 물건을 다시 열어서 죄송합니다. 이것이 올바른 장소가 아니라면 저를 용서하십시오. 그러나 청사진 모형을 개발하기 위한 연구를 하면서 이 토론을 찾았고 이것이 지금까지 내가 찾을 수 있는 가장 가까운 것입니다.

내 응답을 모델별로 분할하는 데 어려움을 겪고 있습니다. (. 모델을 다른 폴더로 참조하는 것이 가능하지 않습니까?
내 청사진 폴더 안에 내 모든 요청을 넣고 싶습니다. 예를 들어 분리된 모델 폴더에 내 모든 엔티티 모델(MSON/MD/JSON/무엇이든 적합한 파일)을 넣어 다른 응답으로 쉽게 재사용할 수 있습니다. 누구든지이 일을 성공적으로 수행 했습니까?

clucasalcantara 에 2018년 08월 05일

Api-blueprint: 외부 자산

가장 유용한 댓글

모든 43 댓글

관련 문제