タグ

apiに関するcalpoのブックマーク (9)

  • 各社のログインAPIで返ってくるIDは何であるのかと、PPIDの現状について

    You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

    各社のログインAPIで返ってくるIDは何であるのかと、PPIDの現状について
  • CORSまとめ - Qiita

    今更ですが、CORS (Cross-Origin Resource Sharing)を色々試していたら、思っていた以上に色々パターンがあることに気づいたので、改めてその扱い方についてまとめてみました。 そもそも 現在のWebブラウザでは、あるWebサイトが持つ情報が別の悪意あるWebサイトに悪用されるのを防ぐために、Same-Origin Policy(日語では同一生成元ポリシー)が適用されます。 例えば、あるWebサイト https://guiltysite.com をブラウザで表示している時に、このWebページからXMLHttpRequest(以下、XHR)やFetch APIで別のWebサイト https://innocentsite.net からHTTP(S)でデータを読み込もうとすると、エラーになる、というわけです。 しかし、アクセス元が悪意あるWebサイトならともかく、データ

    CORSまとめ - Qiita
    calpo
    calpo 2017/02/27
  • Swagger-PHPについてLaravel 5.2で確認したメモ – hrendoh's tech memo

    SwaggerのPHP実装であるSwagger-PHPの使い方についてLaravelプロジェクトで確認し、Swaggerとはどんなものか調査したメモになります。 Swaggerの全体像については、「RESTful APIの記述標準化を担うSwaggerとは? | NTT Communications Developer Portal」が参考になりました。 Swaggerを利用したアプリケーション開発は、まずSwaggerドキュメントを作成して、サーバーのスタブとクライアントライブラリを生成し、APIロジックとクライアントUIなどを実装していくような流れになるといったところのようです。 Laravelはありませんが、コード生成ツール swagger-codegen には、Laravelの軽量版であるLumen用のサーバースタブは生成可能です。 この記事では、Laravel 5.2プロジェクト

    Swagger-PHPについてLaravel 5.2で確認したメモ – hrendoh's tech memo
    calpo
    calpo 2017/02/27
    Swaggervel の利用
  • Swagger-editorの使い方兼気になったこと覚書 - Qiita

    初めに 仕事でSwagger-Editorを使うことになった。 んだが日語のドキュメントが見当たらないので使い方兼覚書を作成。 使い始めて1週間もたってないので気づいたことがあったら順次更新していく所存。 ※後で清書する(とおもう) 英語でいいぞい、という人は↓とかで https://github.com/swagger-api/swagger-editor 環境構築 ↓をクリックすればswagger-editorが開く。楽。 http://editor.swagger.io/#/ Web上に会社のアレコレを書くのはちょっと…という人はDocker使うのが一番楽。 常に最新のバージョンが使えるのでいい感じ。 やることはDockerをターミナルで起動させた後、以下のコマンドをたたくだけ。 docker pull swaggerapi/swagger-editor docker run -p

    Swagger-editorの使い方兼気になったこと覚書 - Qiita
  • 綺麗なAPI速習会 - Qiita

    Wantedly Engineer blogに速習会資料を閲覧向けに再編しました! ぜひご覧いただけると幸いです! 記事は、綺麗なAPI速習会@Wantedlyの資料として作成されたものです。 同時にこちらのコードも参照してください。 マイクロサービス 流行りのマイクロサービス、何がいいのか 各々自由な言語やArchitectureでサービスを立てられる 障害の影響が部分的 変化に強い 個別デプロイ etc... マイクロサービス化をすすめるにあたり、やりとりは全てAPIで行う 内部のAPIであっても外部に公開できるようなクオリティのAPIを作成し、それを元にサービスを作っていくことが重要 APIGatewayとBFF API Gateway Pattern 公式サイトより 「見た目はモノリシック、実装はマイクロサービス」 一箇所見に行けば全てのAPIを見つけられる 細かい権限管理も可

    綺麗なAPI速習会 - Qiita
  • 大量メッセージが来ても安心なLINE BOTサーバのアーキテクチャ - Qiita

    Help us understand the problem. What is going on with this article? 3月24日に発表になったLINEのBOT API Trial Accountが、いよいよ4月7日から実際に試せるようになりました。既に多くのBOTが開発者の手によって作られ始めたようですね。QiitaにもいくつかBOTの作り方が投稿されていますので、"LINE BOT"というキーワードで探してみてください。 実際の作り方の基は他の投稿に任せるとして、BOT API自体は非常にシンプルな作りなので、試すこと自体はすぐにできると思います。しかし、シンプルな反面、仮に近い将来「Trial」が取れて、友だち50人制限が撤廃された時、それでも正しく安定的に動作するBOTとするには、アーキテクチャ上の工夫が必要になります。個人的に、既にLINE BusinessCo

    大量メッセージが来ても安心なLINE BOTサーバのアーキテクチャ - Qiita
  • 翻訳: WebAPI 設計のベストプラクティス - Qiita

    これは Enchant の開発者である Vinay Sahni さんが書いた記事「Best Practices for Designing a Pragmatic RESTful API」1を、ご人の許可を得て翻訳したものです。 RESTful な WebAPI を設計しようとすると、細かなところで長考したり議論したりすると思います。また、他の API に倣ってやってはみたものの、当にそれでいいのか、どうしてそうしているのか分からない、何てことも少なくはないと思います。 この記事では、そのようなハマリどころについて Vinay さんなりの答えを提示し、簡潔かつ明快に解説してくれています。 今後 WebAPI を設計される方は、是非参考にしてみてください。 なお、誤訳がありましたら編集リクエストを頂けると幸いです。 まえがき アプリケーションの開発が進むにつれて、その WebAPI を公

    翻訳: WebAPI 設計のベストプラクティス - Qiita
  • HTTPステータスコードを適切に選ぶためのフローチャート : 難しく考えるのをやめよう | POSTD

    HTTPステータスコードを返すというのはとても単純なことです。ページがレンダリングできた?よし、それなら 200 を返しましょう。ページが存在しない?それなら 404 です。他のページにユーザをリダイレクトしたい? 302 、あるいは 301 かもしれません。 I like to imagine that HTTP status codes are like CB 10 codes. "Breaker breaker, this is White Chocolate Thunder. We've got a 200 OK here." — Aaron Patterson (@tenderlove) 2015, 10月 7 訳:HTTPのステータスコードのことは、市民ラジオの10コードみたいなものだと考えるのが好きです。「ブレーカー、ブレーカー、こちらホワイト・チョコレート・サンダー。200

    HTTPステータスコードを適切に選ぶためのフローチャート : 難しく考えるのをやめよう | POSTD
    calpo
    calpo 2016/02/20
  • Twitter APIのsince_idの仕様を勘違いしていた… - 風柳メモ

    この記事は REST API version 1 時のものです。 REST API version 1.1 ではGET statuses/user_timelineの仕様自体が変更となっていますので(例えばpageオプションはなくなっている等)、この記事は参考にはなりません。ご注意ください。 statuses/user_timeline APIを使って、特定ツイートの前後のツイートを取得する動作をさせようとして、since_idオプションの仕様を勘違いしていたことに今更気がついたので、覚書ついでに恥をさらしておきます。 max_idの仕様は直感的なんですよね 特定ツイート以前(直前)のものを取得するのはとくに問題無くて、 max_id. Returns only statuses with an ID less than (that is, older than) or equal to

    Twitter APIのsince_idの仕様を勘違いしていた… - 風柳メモ
  • 1