HTTPie for Web — API testing clientStart testing REST, GraphQL, and HTTP APIs from the browser in 1s. Free, no account needed.
RFC的に、HTTPヘッダってどんな値を使えるんでしたっけ？のメモ - 小野マトペの納豆ペペロンチーノ日記
Web APIを開発していると、HTTPのヘッダについてRFCにおける規約を確認しなきゃいけない場面がたまにあるので、今回調べたことをまとめた。 HTTP/1.1のRFC HTTP/1.1のRFCといえば、長らくRFC2616であったが、2014年にRFC7230〜7239が発行され、2616は廃止された。 RFC2616 ハイパーテキスト転送プロトコル -- HTTP/1.1 RFC7230〜RFC2739 HTTP/1.1 — RFC 7230 〜 7235 — 日本語訳 両者の変更点については、RFC 723xの付録に記述されているので参照のこと。Content-MD5が廃止されたり、ちょいちょい面白い。文章としても723xの方が分かりやすくなっているので、一度目を通しておくことをお勧めする。 HTTP/1.1 が更新された | The Long Wait あたらしいHTTPの話をし
Shibu's Diary: cURL as DSLとは何だったのか。あるいは細かすぎて伝わらないcURL as DSL。
渋日記@shibu.jp 渋川よしきの日記です。ソフトウェア開発とか、ライフハックを中心に記事を書いていきます。 By Jeremy Brooks under CC BY-NC 先日、cURL as DSLというツールを公開しました。その後、何度も同じような質問を受けたりしたので、ブログにまとめてみます。 なぜこのツールを作ったの？ RESTfulというものは大分一般的になってきました。HTTPでAPIを提供というのもよく見かけます。ですが、僕はこのRESTfulというやつが嫌いです。 GETのURLをシェアすればいつでも同じページがある(変な状態を持たない)、みたいな思想はいいんですが、HTTPのAPIはどうも使いにくい。ドキュメントのHTTPのサンプルを見て、ドキュメントをじっくり読み込んで、パラメータをJSONやらXMLで組み立ててボディに乗っけて(しかも大抵パラメータがアホのように
LivingSocial: SOAにおけるクライアントキャッシュの留意点 - ワザノバ | wazanova
https://techblog.livingsocial.com/blog/2014/08/06/soa-series-part-4-caching-service-responses-client-side/ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 LivingSocialのSOAについてのエントリー。今回紹介しているのは、サービス側からのレスポンスをクライアント（この場合のクライアントの定義は、エンドユーザが使うアプリ、もしくは構成によっては別のサービス）にキャッシュすることで、コストのかかるクライアント/サービス間のコミュニケーションを減らす試み。 Building caching into your client gem LivingSocialでは、通常のHTTP通信やJSONのシ
RESTful APIとしてのRailsとクライアントとしてのJavaScript - ppworks.jp
RailsにおけるRESTfulなURL設計勉強会 千駄ヶ谷.rb #12 #sendagayarb にて発表予定の記事です。 この記事は、qiitaのRESTful APIとしてのRailsとクライアントとしてのJavaScriptにも掲載しています。 よくあるAjaxを利用したページの例 Sedndagaya.rbというグループへ投稿出来るサイトがあるとします。 この時、グループのページにアクセスすると、グループの詳細情報と、グループへ投稿された記事が表示されます。 このとき、大きく分けて3つの描写が行われます。 通常のリクエストに対するレスポンスの描写 非同期のリクエストに対するレスポンスの描写 DOM要素のイベントに対するレスポンスの描写 その時の流れは以下のようになります。 エンドユーザーがあるURIをブラウザ経由でアクセスする。 たとえば、 http://example.com
RailsにおけるRESTfulなURL設計勉強会 メモ #sendagayarb - 130単位
zusaar.com - zusaar リソースおよび情報 参加してきました。 以下、粒度にばらつきありますが、気になった点のメモです。ほぼ引用ですが、意図と違う表現になってしまっていたらすみません。 RESTful APIとしてのRailsとクライアントとしてのJavaScript (@ppworks) no title RESTfulの指向で考えると統一されたインターフェースで、URLを見ただけで何するかわかるのが良い JSはassetsのほうに統一しアクションごとに処理が書けるjQuery-Routerなどを使うと良いのでは RailsはだんだんAPI化していくのではないか 通常のHTTPリクエストと非同期HTTPリクエストを同じ統一インターフェースであるRESTfulな設計で管理すると一貫性が出て開発効率の向上につながる リソースモデリングパターンの提案 (@tkawa)
PHPでTwitter APIのOAuthを使う方法まとめ
この記事以降 Twitter API の仕様が変わっており、このままでは正しく機能しない場合があると思います。近いうちに今のやり方を書くので、それまで参考程度にご覧ください。 Twitter API の OAuth でひととおりやってみた。 忘れないようにメモ。 大雑把な流れ Twitter にアプリケーションを登録する。 Consumer Key と Consumer secret を取得する。 リクエストトークンを取得する。 認証用 URL を取得する。 ユーザーから承認を受ける（bot の場合は自分でやる）。 アクセストークンを取得する。 API にアクセスする。 以下、やった作業の手順です。 事前準備 HTTP_OAuth を使えるようにする OAuth の通信部分そのものは PEAR の HTTP_OAuth を使うことにしたので これをインストールする。 一番めんどくさい部分を
yohei-y:weblog: HTTP ステータスコードを正しく使おう
先月、ぐるなび API がリリースされていました。 ぐるなびさんの持っている膨大なデータベースに Web API を通して気軽にア クセスできるようになったのは、非常に喜ばしいし、その英断に感謝したいと 思います。 しかし、Web API 仕様書、特にエラー仕様を見てちょっとがっかりしました。 もう少し上手にデザインすれば、もっとよかったのに…、という思いです。 一度出してしまった API はそう簡単に変えられないと思いますが、 参考までに僕だったらどうするか、を書いてみます。 この仕様の一番の問題はエラーコードです。 以下は 2-2 のエラー仕様に記述されているサンプルです。 <?xml version="1.0" encoding="UTF-8"?> <gnavi> <error> <code>602</code> </error> </gnavi> タグが三つ(gnavi, erro
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
RequestBin — A modern request bin to collect, inspect and debug HTTP requests and webhooks - Pipedream