You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

JSON Schemaを用いた各種ライブラリやMarkdown生成ツールなどが出てきているが、実際に運用しようとしたときに試行錯誤し、最終的に落ち着きそうな形が見えてきたので共有したい。 良さそうな書き方 ファイルを分割しない。するならHyperSchemaファイルごとに JSON (Hyper)Schemaファイルを書くと一瞬で行数が巨大化する。 そのため現状では、各Schemaファイルをツールにより結合して巨大な一枚のファイルに結合する方法があり、prmdが用いられているのをよく見る。 ただこれにはいくつか問題があり、 結合後のSchemaにより発生したエラーを追いにくい 各ファイルで定義されたSchemaを参照する際に、エディタなどの補助がなければ辛い をどうするかという話が出てくる。 全体を一枚のファイルで書くと、極めて原始的だが、参照性の問題や、 結合の方法が原因のエラーを考えな
最近のウェブ開発では各機能ごとをAPIでつなぎ込む時代になっています。 そのため、各チームが開発をしていく上で、 他のチームにAPIの仕様を伝える方法をきちんとまとめておく必要が出てきています。 そんな中でAPIドキュメントにどのような役割が求められていて どのような選択肢があるか、一旦自分の把握している知識をまとめています。 (ここで書いているAPIは、httpでアクセスしたら、JSON形式でレスポンスを返すウェブサービスのAPIを指しています) APIドキュメントを用意する上で、すぐにぶつかる壁 APIドキュメントを用意する場合に、何も考えずにExcelやwikiにまとめると、早い段階で メンテナンスのコスト の問題にぶつかります。 『APIドキュメントを書く時間がない』 『本当にドキュメント通りの結果が返ってくるか、試してみないとわからない』 『実際に返ってくるAPIとレスポンスが違
We’ve recently gone on record indicating our commitment to using JSON Schema as the format for describing our API’s, then even further by releasing a set of tools to improve the process of building and working with schema-based HTTP API’s. With the recent rise of great API description formats over the last few years like Swagger, Blueprint, and RAML (among others), I wanted to write a few words on
Today we’re open sourcing the toolchain Heroku uses to design, document, and consume our HTTP APIs. We hope this shows how Heroku thinks about APIs and gives you new tools to create your own. This toolchain includes: An HTTP API design guide, describing how we structure both internal and public-facing APIs and document them using the JSON Schema standard. A tool for working with JSON schemas and u
Stay Relevant and Grow Your Career in TechPremium ResultsPublish articles on SitePointDaily curated jobsLearning PathsDiscounts to dev toolsStart Free Trial7 Day Free Trial. Cancel Anytime. Key Takeaways PRMD is a Ruby gem that facilitates the creation, validation, and documentation of JSON API schemas, making it a crucial tool for developers working with JSON APIs. The gem offers a structured app
$ bin/rails g scaffold user name:string mail:string password:string invoke active_record create db/migrate/20151214145437_create_users.rb create app/models/user.rb invoke test_unit create test/models/user_test.rb create test/fixtures/users.yml invoke api_resource_route route resources :users, except: [:new, :edit] invoke scaffold_controller create app/controllers/users_controller.rb invoke test_un
2016年1月5日現在において、JSONを受け取り、返却するWeb APIを書くときに、人が作った規格に乗って楽をしようぜと考えた。 その過程で調べた、JSON Schemaについてメモ書き。間違ってたらツッコミよろ。 概要 JSONの構造を記述する規格。構造の記述そのものもJSONで書かれる。 Draft v4現在では、JSON Schemaは以下の3つの規格の総体を指す。 JSON Schema Core JSON Schema Validation JSON Hyper-Schema そもそも提案された初期のJSON Schemaは、JSON Schema Core+JSON Schema Validationとほぼ同じ領域をカバーしていた。整理・発展の上3仕様に分割された。よって、JSON Schema Core+JSON Schema Validationにあたるものを単にJSO
@izumin5210 こういうのある interagent/prmd https://t.co/QW9oCp0Lzh— ダメになるクッション (@r7kamura) December 22, 2014 gems prmdでscaffold jdocでドキュメント生成 rack-json_schemaでmockサーバ作ったりvalidationしたり… # Gemfile # ... gem 'rack-json_schema' group :development do # ... gem 'prmd' gem 'jdoc' end usage yamlで書けるのは楽.jsonよりは…. # doc/meta.yml --- "$schema": http://json-schema.org/draft-04/hyper-schema description: A schema forG
JSON SchemaでAPI開発を自動化する Tweet このエントリは弊社の英語ブログのAutomating your API with JSON Schema — Commerce Hack の翻訳です。 APIのドキュメントとクライアントライブラリの保守には苦労します。時間もかかるし、ドキュメントの更新をついつい忘れてしまうこともよくあります。私たちは、こういう作業をするのにいいツールはないものか、ずっと探していました。 そして見つけたのが JSON Schema です。これは本当にクールな技術で、私たちはこれを、APIのドキュメント生成、クライアントライブラリ内のロジック、そして自動化テストの中で活用しています。ここではその活用法を紹介したいと思います。 JSON Schema とは何か? JSON Schema とは、JSON object の記述と検証のための標準で、概略はこ
REST API用のドキュメントを生成するときにどうやってるかについて雑記を残しとく。 概要 実装とドキュメントの乖離を避けるためには、同じ意味情報を二箇所以上に定義することを避ける必要がある。そのための方法として、実装それ自身か、もしくは実装が参照している何らかのメタデータを元にしてドキュメントを生成したり、テストの実行結果からドキュメントを生成するというパターンがある。 テストから Cookpadでは、autodocというライブラリを利用して、RSpecでテストを実行している途中で得られたメタデータからドキュメントを生成している。これはテストの実行結果からドキュメントを生成するパターン。 これは実現方法としてはかなり特殊な部類。このパターンが最も効果的に働くのは、ドキュメント生成のために余分な開発コストはあまり掛けたくないが、テストは真面目に書いている OR 真面目に書いてほしい、とい
こんにちは、r7kamura です。 最近は主にイカとして活動しており、カラフルな墨を掛け合う日々を送っています。 さて、QiitaおよびQiita Teamでは、Qiita API v2としてデータを操作するためのREST APIを公開しています。これまで開発者向けに APIドキュメント を提供していましたが、今回は主に機械向けのインターフェースとして、JSON Schemaで記述したREST APIのスキーマ定義 (以下スキーマ) を公開することになりました。具体的には、JSON Hyper-Schema draft v4 を利用して定義されています。 http://qiita.com/api/v2/schema Qiita API v2のスキーマの説明Qiita API v2のスキーマの構成について簡単に説明します。スキーマは http://qiita.com/api/v2/sche
TL;DR JSON Schemaを使ってこういうことが実現可能になった。 ダミーAPIサーバの提供 ドキュメントの自動生成 APIクライアントの動的定義 APIサーバのバリデータの動的定義 APIサーバのレスポンスの自動テスト JSON Schemaとは JSON SchemaというのはあるJSONのデータ構造を記述するための方法および書式の仕様で、 JSON SchemaもJSONで記述される。 これを利用すれば、リソースベースの(=RESTfulライクな)APIの仕様が簡便に記述できる。 例えば、我々のAPIはレシピとユーザというリソースを扱っていて、 それぞれCRUDのAPIを備えており、レシピはidとtitleとdescriptionという属性を持つ、 という旨をJSON Schemaで表現できる。 なんで最近ちょっと流行ってんの Mobile First、 Service Or
内部用APIであるか外部の開発者向けのAPIであるかに関わらず、ドキュメントと実装との乖離は極力避けたいものであるが、注意深く開発を進めない限りこの状況は容易に起こり得る。何が乖離を引き起こし、どうすればこの状況を回避できるのか考えながら、JSON Schemaの利用例を紹介する。なおこの投稿では、HTTP経由でデータの通信を行うような狭義のAPIのことをAPIと呼ぶことにする。 同じ情報源を参照する APIドキュメントと実装が同じ情報源を参照するようにすれば、論理的に関連した要素は統一的に変更され、これらの変更は完全に同期が取れたものになる。つまり、変更時に乖離が生じにくくなる。但し情報の見せ方によって乖離が発生する可能性は十分にだろうし、乖離が発生するのは理解しようとする側の認識の問題であるから、論理的に全く起こり得ないということではない。 この参照の形には、両者が別の情報源を参照する
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く