The Collaborative API Development Platform
New Release - Insomnia 8.0 is finally here with Scratch Pad, Real-Time Collaboration, Enterprise SSO, AI-Generated Testing Design, debug, and test APIs locally or in the cloudChoose Local, Cloud, or Git storage to build better APIs collaboratively with a dev-friendly UI, built-in automation, and an extensible plugin ecosystem. Get Started for Free
RESTとJSON、スキーマ定義について思うところ
mozaic.fm #7 RESTや#mozaicfm REST を聴いての感想、それから「Web+DB vol82のWebAPIデザインの鉄則」に触発されたので書こうと思う。 REST設計について WebAPIを設計するうえでRESTが重要であることは周知のとおりである。 “Constraints are liberating”「制約は自由をもたらす」 @t_wadaさんがおっしゃっているように、RESTを前提にすれば、「アーキテクチャとしてもそうだし、アプリケーションフレームワークも「適切な制約」を設けることで設計のコストが下がる」という大きなメリットが生まれる。 しかし、相変わらずリソース設計やらインターフェース設計やらで悩んでおられる方も多いと聞く。 その一方で個人的には適切なフレームワークを使えばREST設計で悩まなくてもよいはず(※3)という思いもある。 インターフェース設計な
REST APIの認証方法を調べてみた
ある日、REST APIの認証方法をまとめる（という話を聞く）機会があったのですが、要件と各社の実装方法を照らし合わせるとさまざまなケースが存在して興味深かったので、ブログにまとめてみることにしました。 ＃OAuthは「認証」ではなく「認可」の機構であるとか、人の認証とプログラムの認証がごっちゃになってたり、いろいろツッコミどころの多い内容かと思いますがご容赦を。。 求められていた要件（と検討ポイント） Webアプリ以外にバッチプログラムからの利用も想定したい 通信経路中での盗聴や改ざんを防止したい APIトークンの発行などのアカウント管理の手間を軽減したい キーやトークンが漏れた場合の対策をどうするか 1については、特に後者の場合だとPINやOut-of-band(OOB)方式が使えそうですが、「それだと初回やセッション切れた時ににブラウザなど別の認証入るよね？」（いわゆる”火入れ”）と
REST Hooks
Reduce your REST API server load by 66x REST Hooks are a lightweight subscription layer on top of your existing REST API. Start Coding or try a demo app What are REST Hooks? REST Hooks itself is not a specification, it is a collection of patterns that treat webhooks like subscriptions. These subscriptions are manipulated via a REST API just like any other resource. That's it. Really. Read the docs
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
Web API 設計のベストプラクティス集 "Web API Design - Crafting Interfaces that Developers Love" - フリーフォーム フリークアウト
移転しました http://please-sleep.cou929.nu/20130121.html
SOAの未来はRESTか
最も単純な場合、サービスは必要なものをすべて含んだ、独立して開発、配置、管理、メンテナンスができるソフトウエアの実装であり、企業の特定のビジネスと関係のある機能をに提供し、設計によって"統合可能"である、と言えます。ある“サービス”は動詞で定義できます(例えば、“顧客の信用度を検証する”、というふうに実現する機能を表現します)。 サービスはプログラミングの構成概念ではありません。APIのセットでもありません。むしろ、企業の問題解決のために実装される、設計物(部品の設計、実装、メンテナンス)と配置物です。サービスの機能性はサービスのインターフェイス(そのサービス特有の)によって定義されます。このインターフェイスは複数の実装方法で実現できます。サービスのインターフェイスを定義するにはふたつの基本的な方法があります。RPCスタイルとメッセージングスタイルです。RPCスタイルの実装はサービスの起動
JAX-RSでRESTなWebサービスを作ってみる - うなの日記
JAX-RSを使うとRESTFullなWebサービスがさくっと作成できるらしい。ということで試してみました。 概要 Webサービスを公開するまでの手順は以下の通りです。 JAX-RSの実装(Jersey)をダウンロード Webサービスとするクラスを書いて、アノテーションを付ける。 HTTPサーバーを起動するランチャを書く。 作成したクラスをコンバイルして実行。 以上。JAX-WSでWebサービスを作るよりもさらに簡単です。 1.JAX-RSの実装(Jersey)をダウンロード JAX-RSの実装であるJerseyをSunのサイトからダウンロードします。mavenのリポジトリも公開されているみたいですが、とりあえずzipになっているものを取得して使用しました。ダウンロードして展開し、lib以下のjarをパスに通せば開発環境の用意は完了です。 2.Webサービスクラスを書いて、アノテーションを
Kazuho@Cybozu Labs: REST におけるトランザクションについて (Re: Web を支える技術)
といいつつ、ひとつだけ理解できないというか、納得できないところが。トランザクションのところがなんだかRESTっぽくないのがすごく気になる Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESSプラスシリーズ)(山本 陽平) - ただのにっき(2010-04-23) 「Web を支える技術」は自分もとてもいい本だと思う (教科書としてすばらしいし復習用としても読みやすいのでイイ) のですが、トランザクションの所だけは分かりづらいなと感じました。その原因は、atomic transaction で解決できる課題を例として使っているという点と、トランザクションと更新クエリのレイヤ分割がされていない、という２つの点によるものではないでしょうか。 HTTP 上でトランザクションを表現する必要があるケースのほとんどは、atomic transaction ではなく
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
WebAPIのこれまでとこれから
Content Error