Как я могу использовать пасеку с JSON-RPC

Я пытаюсь использовать apiary.io для документирования API на основе JSON-RPC. Я могу отформатировать страницы, но консоль просто не работает.

С JSON-RPC у вас обычно есть только 1 URI, как в случае с нашим API. Из-за этого при попытке определения методов редактор чертежей выдает предупреждение

Action with method POST already defined...

Я подумал, что могу игнорировать это, но в консоли пасеки при тестировании он будет возвращать пример ответа только для первого определенного действия. У кого-нибудь есть работа для этого?


apiary.io apiblueprint apiary
person Rob Rodriguez    schedule 27.04.2014    source источник
comment
можете ли вы поделиться хотя бы фрагментом такого плана JSON-RPC?   -  person Zdenek    schedule 12.05.2014

Ответы (2)


arrow_upward
4
arrow_downward

Насколько я понимаю из spec и примеров JSON-RPC, несколько запросов и ответов могут работать на вас лучше, чем определять POST конечных точек несколько раз.

# My API

## JSON-RPC [/endpoint]

### Doing something [POST]
+ Request Sum of numbers (application/json-rpc)

        {"method": "sum", "params": {"a":3, "b":4}, "id":0}

+ Response 200 (application/json-rpc)

        {"result": 7, "error": null, "id": 0}

+ Request Posting a message (application/json-rpc)

        {"method": "postMessage", "params": ["Hello all!"], "id": 99}

+ Response 200 (application/json-rpc)

        {"result": 1, "error": null, "id": 99}

Минусы. Ваш API будет сжат до одной или двух конечных точек, а отдельные запросы не будут видны в ToC.

Плюсы. Логика сопряжения запроса и ответа на фиктивном сервере Apiary позволит вам использовать некоторые стратегии (также описанные на странице, ссылка на которую приведена выше) для вызова ответа, отличного от первого. Однако, поскольку эти стратегии работают только (во время публикации этого ответа) с заголовками или кодами состояния и не проверяют тело полезной нагрузки входящего запроса, вы, вероятно, все равно не сможете легко различить свои запросы в консоли.

Возможным обходным решением может быть добавление дополнительных заголовков к вашим запросам, таких как X-Request: 1, X-Request: 2 и т. д., чтобы фиктивный сервер мог различать их и возвращать вам правильный ответ.

person Honza Javorek    schedule 22.08.2014

arrow_upward
0
arrow_downward

Вы можете использовать трюк с якорем, уникальным путем фрагмента в URL-адресе конечной точки API.

# Group Awesnome JSON-RPC API

## Entity A [/#A]
### Procedure A [POST]
### Procedure B [POST]

## Entity B [/#B]
### Procedure C [POST]
### Procedure D [POST]
person Peter Nikonov    schedule 07.05.2019