APIサーバを立てるためのCORS設定決定版 - Qiita
タイトルは釣り、かつ、自分のための備忘録です。 マイクロサービスアーキテクチャでサービスを構築すると、APIサーバをサービスごとに立てるわけですが、 ブラウザ上のJSエンジンからAPIサーバを叩く時に避けて通れないのが、Same-Origin Policy（同一生成元ポリシー）によるCORS (Cross-Origin Resource Sharing)制限です。 これを回避するには、APIサーバ側でAccess-Control-*ヘッダを適切に返す必要がありますが、どう設定するべきかの情報が意外と少ないので（自分的）これが決定版！ という設定を考えてみました。 結論 nginxの場合の設定例です。 server { listen 80; server_name site.localhost; charset utf-8; root /var/www/app/public; locatio
各ビットコイン取引所APIの認証で陥りやすいポイント - Qiita
ビットコインAPI取引の最初の壁 ビットコイン取引所のAPIを利用しようとして、おそらく殆どの人が最初につまづくのは認証の部分でしょう。 各取引所で微妙に仕様・作法が異なる上、エラーになっても「認証に失敗しました」などの、なんの手がかりも与えてくれない無慈悲なメッセージが帰ってくるだけです。 私自身も裁定取引のアプリケーションを作るにあたり、新しい取引所を追加するたびに、認証方式の微妙な違いにぶつかり手間取ってしましました。 自分の失敗を晒すことで、この記事が今後API取引にトライする方々の助けになればと思います。 認証のフロー はじめに、認証の一般的なフローを説明します。 プログラミング言語にかかわらず、HTTPリクエストを作成するという観点では同じフローになります。 取引所Webサイトからキー、シークレットを発行する。 各オペレーション(オーダー送信、ポジション取得等)のAPIのURL
翻訳: WebAPI 設計のベストプラクティス - Qiita
これは Enchant の開発者である Vinay Sahni さんが書いた記事「Best Practices for Designing a Pragmatic RESTful API」1を、ご本人の許可を得て翻訳したものです。 RESTful な WebAPI を設計しようとすると、細かなところで長考したり議論したりすると思います。また、他の API に倣ってやってはみたものの、本当にそれでいいのか、どうしてそうしているのか分からない、何てことも少なくはないと思います。 この記事では、そのようなハマリどころについて Vinay さんなりの答えを提示し、簡潔かつ明快に解説してくれています。 今後 WebAPI を設計される方は、是非参考にしてみてください。 なお、誤訳がありましたら編集リクエストを頂けると幸いです。 まえがき アプリケーションの開発が進むにつれて、その WebAPI を公
登録されるとつらいユーザー名リスト - Qiita
Twitter, GitHub, Qiita などのように root/(username) でユーザーページをルーティングするところが増えてきている. このルーティングを採用し, help などのユーザー名を許可すると, root/help が奪われてしまう. そこで, 登録時に validate で, ある程度排除するのが習わしになっていると思うが, 急に root 直下に置きたいページが増えたときなどに取得されていると悲しいことになる. また, サブドメインを利用するサービスだと, api などをうっかり取られてしまうケースが後を絶たない. http://api.hatenablog.com/ みたいに取られることによる面白みもあるが, おおむねつらい. 実際, twitter では search アカウントが取られていて, TweetDeck では twitter.com/searc
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Android-iOS API対応表(2) - Qiita
