BGPView allows you to debug and investigate information about IP addresses, ASN, IXs, BGP, ISPs, Prefixes and Domain names.
apiaryに関するishideoのブックマーク (12)
-
ishideo 2020/03/18
-
API Blueprintで書いたWeb APIをdreddでテストする - Qiita
前々回：API BlueprintでWeb APIのドキュメントを生成する - Qiita 前回：API Blueprintとapi-mockでモックサーバを作成する - Qiita 概要 さて、今回はAPI Blueprintを使って作成したWeb APIがドキュメント通りに動作するかを、dreddを使ってテストします。 dreddとは dreddはAPI BlueprintをベースにしたWeb APIのテストフレームワークです。"Language-agnostic"と謳っているだけあってテストのフックにはnode.js以外にもgoやPython、Rubyなど多様な言語が利用でき、またCircleCIやJenkinsCIなどのCIのサポートもあります。 このように、API Blueprintのエコシステムに乗っかることによって、API Blueprint形式で書いた仕様からaglioを使
-
-
GoConの前哨戦として各種API仕様記述フォーマットについて概要を述べておく - Qiita
この記事はGoCon 2016 springで話す内容を圧縮するためのものです。 WebサービスのAPI仕様を記述したりするためのそれなりに有名な仕様について、筆者(@vvakame)の私見を述べていく。 なお、Google Trendの結果を見ると…。 仕様を調べてSwaggerを選択する事にしたのは1年弱程度前のはずなので、もし "今はそれもうできるよ！" とかあったらコメントなどで教えてください。 RAML RESTful API Modeling Language なので、手書きを前提にしている。 YAMLで頑張って仕様を書く。 Spec APIs Explorerっぽいものもあるっぽい。 総評 比較的広く使われているようでパワを感じる。 まず仕様が先というスタイルなのがめんどくさそう。 YAMLなのがちょっとイヤ。 RAMLからGoとJavaScript(TypeScript)向
-
APIドキュメントを支える技術 - Qiita
最近のウェブ開発では各機能ごとをAPIでつなぎ込む時代になっています。 そのため、各チームが開発をしていく上で、 他のチームにAPIの仕様を伝える方法をきちんとまとめておく必要が出てきています。 そんな中でAPIドキュメントにどのような役割が求められていて どのような選択肢があるか、一旦自分の把握している知識をまとめています。 (ここで書いているAPIは、httpでアクセスしたら、JSON形式でレスポンスを返すウェブサービスのAPIを指しています) APIドキュメントを用意する上で、すぐにぶつかる壁 APIドキュメントを用意する場合に、何も考えずにExcelやwikiにまとめると、早い段階で メンテナンスのコスト の問題にぶつかります。 『APIドキュメントを書く時間がない』 『本当にドキュメント通りの結果が返ってくるか、試してみないとわからない』 『実際に返ってくるAPIとレスポンスが違
-
-
【Noby API】ノビィ取り扱い説明書 使い方編【CotoGoto】 - Qiita
こんにちは。この記事は【Noby API】ノビィ取り扱い説明書【CotoGoto】の続きの記事になります。 今回は使い方についてを説明していきます。 1. 認証キーの発行 認証キーの発行は以下の手順で行います。 1-1. API利用の場所 CotoGotoの下のリンクからAPIをクリックします。 1-2. ユーザ登録 アカウントとAPIキー取得から次のページに遷移します。 Line or Facebookで ユーザ登録を行います。 1-3. 認証キーの発行 認証キーが発行されます。 2. APIを動かしてみる APIの動作確認はApiaryからも動作確認を行うことができます。 3. JavaScriptでAPIを実装する 次にJavascriptでAPIを実装します。 3-1. HTMLのテンプレートを作成 HTMLのテンプレートを作成します。 <!DOCTYPE html> <html
-
API Blueprintとその周辺ツール - Qiita
APIを作る機会が増えてきている 例えばマイクロサービス間はAPIでやりとりすることが多い。 外部のサービスもだいたいAPIでやりとりする。 社内APIもいくつかあるが、いざ使おうとなるとどんなリクエストを送るべきなのか、またどんなリクエストが返ってくるのかを調べるのが面倒。 API ドキュメントを書くのは大変 フォーマットは？ Markdown? HTML? Text? エンジニア間で書き方がバラバラにならない？ そのドキュメントの内容は今も正しい？ そもそも書くのが面倒… ということで、いい感じのAPIドキュメントツールがほしい API ドキュメントツールに求めること その1 ドキュメントが書きやすい ドキュメントが読みやすい ドキュメントがGitで管理しやすい リクエスト情報、レスポンス情報が見やすい curlですぐに試せるようにサンプルがほしい ドキュメントとコードに乖離がないよう
-
TokyoMetroOpendataAPI · Apiary
A place where APIs are kept.
-
「東京メトロオープンデータ活用コンテスト」②APIの仕様設計を理解し、ドキュメント化する - Qiita
成果物：apiary.ioによる、APIドキュメント とりあえず見て貰えるとイメージつかみやすいです↑ あらすじ 100万円欲しいのでAPIを利用したアプリ開発を学ぶ絶好の機会なので、東京メトロオープンデータ活用コンテストに挑戦しようとしている。 前回、とりあえずざっと触ってみてAPIのイメージは掴んだ 今回は、公式ドキュメントと実際のレスポンスを咀嚼して、仕様設計を汎用ドキュメント化しつつ理解していくことを目的とする せっかくドキュメント化するからには、汎用性と実用性が高いフォーマットとしたい（オレオレにはしたくない） 成果物 API Blueprintで記述されたテキストをApiary.ioでホスティングし、以下を作った TokyoMetroOpendataAPI · Apiary github上のソース（markdownプレビュー版） やってみてわかった、ApiaryによるAPIドキ
-
-
効率の良いAPIモック作成について - Qiita
概要 アプリの開発を進めるには、APIの仕様 + API仕様通りのレスポンスを返すモックがあると捗る モックを簡単に効率良く作成する方法を調査 調査・検証 1.自分で仕様から書き起こす 長所 好きな言語で書ける 普段書かない言語を選択すればスキルアップ 短所 地味に大変 実際に使うときが面倒(ローカルか開発サーバ) 使いまわせない 時間がかかる 仕様変更ごとにコードを修正 2.JSONSchemaからの生成 長所 JSON SchemaでAPIを設計することでfieldの型など仕様が明確になる。 APIのレスポンスが正しいかValidationするのに使える。 サーバ、クライアントどちらでもテストに使用できる ドキュメントを自動生成できる。 短所 書くのが大変 json_worldというRubyのDSLでJSON Schemaが書けるgemがある 参考 http://r7kamura.ha
-
1
公式Twitter
- @HatenaBookmark
リリース、障害情報などのサービスのお知らせ
- @hatebu
最新の人気エントリーの配信
キーボードショートカット一覧
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Copyright © 2005-2025 Hatena. All Rights Reserved.
設定を変更しました