チームでのAPI開発の強い味方!!REST APIクライアント「Paw」と「Insomnia」を比較してみた - コネヒト開発者ブログ
こんにちは！今年もコナン映画にいってきました、コナンでは服部派のエンジニア結城(@super_manner)です(*´ڡ`●) さて、今回はAPIをチームで開発するうえでつよーい味方になるツールを２つ使い比べた結果をご紹介しようと思います!! そもそもPawとInsomniaとは？ 双方ともREST APIクライアントです。 Paw paw.cloud Insomnia insomnia.rest APIを作成していると、POSTする必要があったり、User-AgentやRequestHeaderによる制約を受けたりで プラグイン追加が加速したりしますよね。 うっかりそのまま他のサイトを閲覧して全部がxmlで表示されたりすることもしばしば。 そんな煩わしさも、これらのクライアントを使うことで開放されるのです!! APIをメインに開発されている方にはもはや必需品になっているかもしれませんね。
REST API仕様からAPIクライアントやスタブサーバを自動生成する「OpenAPI Generator」オープンソースで公開。Swagger Codegenからのフォーク
REST API仕様からAPIクライアントやスタブサーバを自動生成する「OpenAPI Generator」オープンソースで公開。Swagger Codegenからのフォーク RESTful APIの仕様を基に、APIクライアント用SDK、APIクライアントのテスト用にAPIサーバのように振る舞ってくれるスタブサーバ、Webサーバのコンフィグレーション、ドキュメントなどを自動生成してくれる「OpenAPI Generator」がオープンソースとして公開されました。 RESTful API仕様の記述フォーマットは、2015年にマイクロソフトやGoogle、IBMらが立ち上げた「Open API Initiative」が提唱する「OpenAPI Specification」が事実上の業界標準となっており、OpenAPI GeneratorもこのOpenAPI Specificationを基に開
API デザイン : URL には名前と識別子のどちらを使うべきか | Google Cloud 公式ブログ
ウェブ API の設計に携わっている方であれば、API で使う URL のスタイルに統一的な考え方がないことも、選択した URL スタイルが API の使いやすさや寿命に大きな影響を与えることも、よくご存じでしょう。Google Cloud の Apigee チームは、社内だけでなくお客様とも協力しながら、API の設計について長く検討を行ってきました。本稿では、私たちが設計の現場で実際に使用している URL のデザイン パターンと、それを使う理由についてシェアしたいと思います。 著名なウェブ API をご覧になれば、いくつかの異なる URL パターンがあることに気づかれるはずです。次に示すのは、極端に異なる考え方に基づいた 2 つのスタイルの具体例です。 https://ebank.com/accounts/a49a9762-3790-4b4f-adbf-4577a35b1df7 htt
AJAX APIs Playground
Google APIs Explorer Stay organized with collections Save and categorize content based on your preferences. The Google APIs Explorer is a tool available on most REST API reference documentation pages that lets you try Google API methods without writing code. The APIs Explorer acts on real data, so use caution when trying methods that create, modify, or delete data. For more details, read the APIs
Best Practices for Designing a Pragmatic RESTful API
Your data model has started to stabilize and you're in a position to create a public API for your web app. You realize it's hard to make significant changes to your API once it's released and want to get as much right as possible up front. Now, the internet has no shortage on opinions on API design. But, since there's no one widely adopted standard that works in all cases, you're left with a bunch
Swaggerで始めるAPI定義管理とコードジェネレート
iOSDC 2017 2017/09/15@早稲田大学理工学部西早稲田キャンパス 63号館 Yohei Suginami ( @susieyy )
GoでとあるAPIサーバを実装し直した話 | メルカリエンジニアリング
サーバサイドエンジニアの @b4b4r07 です。この記事は Go Advent Calendar 2016 の 19 日目です。今回は Go (Revel フレームワーク) で書かれていた API サーバをフルスクラッチで書き直したお話をします。 Revel とは A high productivity, full-stack web framework for the Go language 公式の説明にあるように、Revel は高機能でフルスタックな Web フレームワークです。 複雑なルーティングや、パラメータのパーシング、テンプレート機能など、Web アプリケーションを作ろうとなったときに必要な手段はたいてい兼ね揃えているようです。公式ドキュメントに詳しく書かれています。 Revel 以外にも Go 製の Web フレームワークは多数あり、有名どころだと以下のようなものが挙げられ
RESTful API の設計のキホン
2016/10/12 社内勉強会で使ったスライドを社外向けに一部加筆訂正したもの
「WebAPI 設計のベストプラクティス」に対する所感 - Qiita
「翻訳: WebAPI 設計のベストプラクティス」を読んで色々と思うところがあったので書きました。 上記の記事は訳文でありますので、正しくは「Best Practices for Designing a Pragmatic RESTful API」に対する所感と述べた方が良いのかもしれませんが、日本語で通して読めるよう Qiita に投稿された訳文に対する所感として書いています。 以下では「翻訳: WebAPI 設計のベストプラクティス」並びに「Best Practices for Designing a Pragmatic RESTful API」は「当該記事」と表現します。 観点 当該記事では「○○とした方がよい」との意見に対してそうすべき理由が明らかになっていないか、もしくは表現が曖昧な場合が目立っていると感じました。設計は実装のようにプログラム言語仕様が制約を与えられないため、意図
続・リトライと冪等性のデザインパターン - リトライはいつ成功するか - Blog by Sadayuki Furuhashi
三度の飯よりエラー処理。古橋です。 大変好評をいただいた序章リトライと冪等性のデザインパターンの続編です。 前回はほぼ前置きでしたが、今回は冪等でない操作を冪等にする具体的なテクニックもまとめていきます。 パターン２：エラーを区別してDELETEを冪等にする リソースに常に一意なIDが振られていれば、Deleteを冪等にするのは難しくない。そもそも同じリソースを2度削除することはできない。 一つ注意するべきなのは、削除されたリソースのIDが再利用されるケースでは、Deleteの冪等性は保証されない。例えば、kill -KILL <pid> コマンドはDelete系のAPIと考えられるが、pidは再利用されるので、何度も繰り返すと意図しないプロセスを殺してしまう可能性がある。 一般にIDの生成は非常に難しい問題だが、Deleteに関してのみ言えば再利用されなければいいので、単調増加する整数（
リトライと冪等性のデザインパターン - Blog by Sadayuki Furuhashi
リトライを肴に一晩酒が飲める古橋です。 大規模なデータに触れることが日常茶飯事になっている今日この頃。この分野のおもしろいところは、いつまで経っても終わらないプログラムを簡単に作れてしまうことかもしれません。エラー処理、リトライそして冪等性*1の３つを抑えていないプログラムは、小規模なデータなら問題ないが、データ量が多くなると使い物にならなくなる可能性が大です。 大規模データをバッチ処理するケース以外でも、リトライは一般にプログラムの信頼性に関わる重要な問題です。 そんなわけで、リトライに関わるいくつかのデザインパターンを、連載でまとめておこうと思います*2。 では、第1回は背景から： なぜリトライが必要なのか プログラムは色々な理由で失敗する。例えば、 A) 通信先のプログラムが高負荷すぎて応答できなかった B) メモリを消費しすぎてメモリ確保に失敗した。またはOOM KIllerに殺さ
RESTFul(リソース指向アーキテクチャ)について - In urban breeze
2014-05-06 RESTFul(リソース指向アーキテクチャ)について アーキテクチャ ROA(Resource Oriented Architecture)について。 次の本を参考に勉強してみた。参考図書 RESTful Webサービス ROAの基本 アプリケーションを動作と名詞(リソース)で考える。 リソースは特定のデータ、データの演算結果、状態、ユーザーアカウントなどである。 URIに動詞を含めてはならない。 リソースはHTTPメソッドを使用してのみ操作できる。 アドレス可能性 リソースはアドレス(URI)で一意に表現する。 1つのURIが複数のリソースを示してはいけない。 リソースを特定の言語や特定のフォーマットで取得したい場合は「Accept-Language」や「Accept」、または「Media-Type」を使用する。このようにリソースの表現方法が複数あ
拡張可能なWeb APIの設計原則と、バージョン番号を使う理由について
APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sightにはブコメしたのですが、Rebuild: 35: You Don't Need API Version 2 (Kenn Ejima)でも本件に言及があったようなので、少し一般論を書いておきたいと思います。 ■Web APIの設計原則について そもそも、良いAPIとはどのような特性をもつものでしょうか？ 一般的に、以下の２点が挙げられると思います。 拡張が容易である 拡張時に後方互換性を破壊しない ウェブの場合は、これに加え、 スケーラブルである HTTPに起因する問題に上手に対処できる ことが求められます。 前２者はウェブに限らない要件です。これを満たす設計手法としては、 リクエストおよびレスポンスのパラメータを拡張可能に 互換性を壊す拡張が必要な場合は、関数名を変える 古い関数は従来と同じ機能を
APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight
ちょっと前にTwitterでAPIのバージョニングをどうやるかみたいな話をしていたのですが、そのへんもやもやしているので少し整理しておきたいなと。 APIのURLを/api/v1/*とかってやるの、やめたほうがいいとおもうんだけどなぁ。いざv2を作るとなったときに、大量のコピペが発生して後悔するよ、って伝えたい。— Kenn Ejima (@kenn) February 28, 2014 さて、これについて色々と異論・反論も含めた意見が出たのですが、まずは、大昔にURL方式（＝コントローラ分割）でやってきて後悔したぼくが、（5年ぐらい前から）現在はどうやってAPIのバージョンを管理しているか？について紹介します。 基本原理としては、コピペが多発する根っこで分岐（＝コントローラ分割）じゃなくて、必要最小限のところで限局的に分岐するのがいい、という考え方に基づきます。 一言でいうと、「パラメー
APIが有効なケースとそうじゃないケース
Web2.0なんてのが流行語になった時代、いろんなところが自分が持ってるデータをAPIを通じて誰もがアクセスできる様にして、利用者はいろんなAPIをくっ付けることで新しいサービスができる、みたいなのが面白いと思った。 ユーザが更新をするようなデータや、どちらかというとRPCに近いようなものはAPIとして提供すると大変世界が平和になる。Twilioとかすごいよね。 ただ、なんでもAPIにすりゃいいかというとそうじゃない。 特にreadが中心のデータ、例えばスポーツの過去の記録だったり、法令だったり、アニメの放映日だったり。こういうのはみんなが思い思いに更新するわけじゃないし、そもそも更新頻度が低いわけで、そのデータを使ったサービスを作る時に都度APIアクセスしてたら無駄だし、API側もリクエストが無駄に多くて余計な制限をかけることになる。 こういうデータは、たとえデータがそこそこデカくても全
日本気象協会、「過去の天気」データをAPI提供
日本気象協会が「過去の天気」に関するAPIを提供開始。スマホアプリやWebサービスから過去の天気や気温、降水量などを呼び出せる。 過去の天気では、2012年9月17日以降の47都道府県142地域における1日の天気、最高／最低気温、降水量などのデータを利用できる。例えば、スマートフォンアプリやWebサイトのカレンダー上にその日の天気を表示したり、選んた日時の天候に合わせてサイトデザインを変更する――といったことが可能だ。 XMLやJSONなどで出力するREST方式のAPI。利用料は月額6万円からで、初期費用10万円が別途かかる。 天気予報APIではこのほか、週間天気予報、紫外線や花粉の情報、不快指数、ビールをおいしく感じる度合いを示す「ビール指数」、風邪のひきやすさを示す「風邪ひき指数」などのデータを提供している。 関連記事 全国の天気の「今」をマッピング 関連ツイートを地図上に、tenki
pythonapi.com - Domain Name For Sale | Dan.com
Buyer Protection Program When you buy a domain name at Dan.com, you’re automatically covered by our unique Buyer Protection Program. Read more about how we keep you safe on our Trust and Security page. Next to our secure domain ownership transfer process, we strictly monitor all transactions. If anything looks weird, we take immediate action. And if the seller doesn't deliver on their part of the
OpenStack Docs: 2023.2 API references
OpenStack 2023.2 API Reference Documentation This page contains documentation about the OpenStack API and how to use it. API References Application Catalog service (murano): API Reference Backup, Restore, and Disaster Recovery service (freezer): API Reference Bare Metal service (ironic): API Reference Block Storage service (cinder): API Reference Clustering service (senlin): API Reference Compute
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
書誌情報や書影データを高速APIで提供する「openBDプロジェクト」、版元ドットコムのデータをカーリルがAPI化 
失敗から学ぶAPI設計 #ccc_h4 #jjug #jjug_ccc JJUG CCC 2013 Spring
