grpc-gateway と使われてるProtocolBuffer周辺技術メモ - はこべにっき ♨
grpc-gatewayはHTTP2+ProtocolBuffer をプロトコルに用いるgRPCのサービスを、HTTP/1.1のRESTfulな JSON APIとして利用できるようにするリバースプロキシを生成してくれるツールだ。 厳密にはProtocolBuffersを処理するコマンドであるprotocのプラグインとして動作し、protocに読み込んだgRPCのサービス定義をもとにGoで記述されたコードを生成する。生成されたコードはHTTPサーバのハンドラになっていて、net/httpに登録して使えるようになっている。 ハンドラはHTTP/1.1でリクエストを受け取ると、リクエストに含まれるJSONを対応するProtocolBufferのメッセージに変換し、プロキシ先のgRPCサービスのメソッドを呼び出す。このgRPCサービスは、元にしたスキーマが同じであればGo以外の言語で実装されてい
Swagger入門 - 初めてのAPI仕様管理講座(3) Swagger Codegenを使ったコード自動生成のポイント
今回はSwagger Codegenを紹介します。 Swagger Codegenを使うと、Swagger Spec仕様を記述したYAMLやJSONファイルからAPIコンシューマのドライバコードやAPIプロバイダのスタブコードを自動生成できます。Swagger UIと合わせてマスターすることで、Swagger Specを中核に置き、ドキュメントもコードも自動生成することが可能になります。 出力できる言語もC#、Java、golang、負荷試験のためのJMeterなど多岐に渡っており、好みや用途に応じて選択可能な点も見逃せません。インストールから動作確認までの手順をぜひ試してみてください。 インストールと設定 ターミナルにて以下のとおりbrewコマンドを投入し、Swagger Codegenをインストールします。インストール作業はこれで終わりで、特段の設定は必要ありません。 $ brew i
GraphQLはWeb APIの次のフロンティアか？ | POSTD
RESTの規約。URLはリソースであり、CRUDはHTTP動詞にマップされる。 RESTの規約に1つ問題があるとすれば、規約が十分でないということでしょう。上記で”通常”、”多くの場合”、”時に”という表現を使ったのは、これらのやり方は仕様で推奨されているものの守られるとは限らないためです。実世界では、大抵のAPIはRESTishがせいぜいです。例えばStripeでは、リソース更新に PUT ではなく PATCH を使うべきですが、歴史的理由でそうはなっておらず、おそらく現時点では変更に値しないでしょう。いずれにしても開発者はドキュメントを読む必要があり、その時、 POST メソッドのユビキタスな使い方があることに気づくのです。 RESTには他の問題もあります。必要なものだけでなく全てが返ってくるため、リソースのペイロードが非常に大きくなることがあるのです。そして多くの場合、クライアントが
HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様
今日では HTTP(s) で API が公開されることは当たり前の時代ですが、エラーをアプリケーションにどう伝えるかは、個々の API の設計に依存していました。特に、HTTP ステータスコードは有限であり、元々持っている意味があるので、自由に使うことはできません。API はそのドメインごとにもっと複雑で細かなエラー情報があるはずで、それらはレスポンスボディに載せてアプリケーションに伝えることになりますが、その書式に規定は今までありませんでした。 HTTP API にて、アプリケーションにエラー情報を伝達するための（レスポンスボディに載せられる）標準的な形式が、RFC7807 Problem Details for HTTP APIs で定められています。適用例としては、以下のようになります。 HTTP/1.1 403 Forbidden Content-Type: application
マイクロサービスアーキテクチャにおけるAPIコールの仕方とHTMLレンダリング - Qiita
先日、マイクロサービスの呼び出し方として、オーケストレーションとコレオグラフィについて書きましたが、同じく4章では、どうHTMLを組み立てるかという問題が提起されています。 ここもやや難解なので、咀嚼を試みます。 課題設定 次のようなECサイトを考えることにします。そして、4つのマイクロサービスを合成して構成します。 商品カタログサービス ショッピングカートサービス ショップサービス リコメンドサービス API合成 無垢な気持ちで設計すると、各々のマイクロサービスがWeb APIのインタフェースをもち、XMLやJSONを返して、ECサイト側で、テンプレートエンジンなどを用いて、HTMLをレンダリングするという方式になるかと思います。 そして、この形式でマイクロサービスを利用するサイト(アプリケーション)が増えていくと次の図のようになります。 これには、次の3つの欠点があるとされています。
翻訳: WebAPI 設計のベストプラクティス - Qiita
これは Enchant の開発者である Vinay Sahni さんが書いた記事「Best Practices for Designing a Pragmatic RESTful API」1を、ご本人の許可を得て翻訳したものです。 RESTful な WebAPI を設計しようとすると、細かなところで長考したり議論したりすると思います。また、他の API に倣ってやってはみたものの、本当にそれでいいのか、どうしてそうしているのか分からない、何てことも少なくはないと思います。 この記事では、そのようなハマリどころについて Vinay さんなりの答えを提示し、簡潔かつ明快に解説してくれています。 今後 WebAPI を設計される方は、是非参考にしてみてください。 なお、誤訳がありましたら編集リクエストを頂けると幸いです。 まえがき アプリケーションの開発が進むにつれて、その WebAPI を公
Web APIにはJSONベースのフォーマットを使おう - Qiita
{ "response": { "id": 3342124, "message": "Hi!", "user": { "id": 3456, "name": "Taro Yamada", "image_url": "/images/taro.png" } } } など、どの構造がいいでしょうか？ もっと違う構造も考えられます。 JSONはシンプルですが、構造に制約がなさすぎます。適切な設計を行うには適切な制約が必要です。 そこで、plain JSONに少し制約を加えたJSONベースのフォーマットを使うことをおすすめします。 もしあなたが、JSONレスポンスをどのようなフォーマットにするかをチームで議論したことがあるなら、JSON APIは『自転車置き場の議論』に対抗する武器となる。 共有された規約に従うことで、生産性が向上し、汎用的なツールを利用でき、アプリケーションという重要なものに集中
RESTful APIの記述標準化を目指す「Open API Initiative」をマイクロソフト、Google、IBMらが立ち上げ。Swaggerをベースに
RESTful APIの記述標準化を目指す「Open API Initiative」をマイクロソフト、Google、IBMらが立ち上げ。Swaggerをベースに 10年以上前、XMLの登場に続いてXMLベースのAPIを記述する標準フォーマット「WSDL」が提唱されました。 WSDLにはAPIの仕様がマシンリーダブルな形で記述されており、APIを呼び出すためのプロトコルやデータフォーマットをあらかじめ知ることができます。WSDLを利用することで、APIをコールするためのコードを自動生成することが可能でした。 しかしXMLベースのAPIは期待されたほど普及せず、現在ではよりシンプルなRESTful APIが事実上の標準となっています。 そしてRESTful APIのためのWSDLとも言うべき、RESTful APIのインターフェイスを記述するための標準フォーマットを推進する団体「Open AP
オープンソースのAPI Gateway「Kong」
全国100万人のモノリシック巨大アプリケーションに苦しむみなさんこんにちは。 世の中猫も杓子もマイクロサービスだ!!とかAPIだ!!とか言っていますが、実際にマイクロサービス環境にしようとすると、どのようにしてAPIのサービスを取りまとめるかが課題になります。 一般的には以下のようなやり方になります。 複数のサービスに分散しているAPIを統合するゲートウェイを用意するそのゲートウェイでは以下のようなことをおこなうクライアントからのアクセスのシングルエンドポイントの役目を果たすAPIの実体へのルーティング認証アクセス記録の収集スロットリング(過度なアクセスの抑止)実体がダウンしている場合のデグレーションこのようなAPIゲートウェイの機能は既にAWSではAmazon API Gatewayとして提供されていますが、オープンソースでもいくつかのプロダクトがあります。今回はそのうち一番開発が活発そ
WebAPIでエラーをどう表現すべき？15のサービスを調査してみた - Qiita
2017-01-05 追記 2016年3月にエラーの標準形式RFC7807「Problem Details for HTTP APIs」が提案され、今日現在proposed standard(標準化への提唱)となっています。こちらも是非ご覧ください。 RFC 7807 - Problem Details for HTTP APIs HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様 最近はREST APIを提供しているサービスが増えてきていますね！また公開されるAPIだけでなく、Microservicesなアーキテクチャを採用して、バックエンドがWeb APIで通信するケースも増えてきているように思います。 APIを使うときはあまり気にしたこともなかったですが、いざAPIを設計してみるとどんなインターフェイスがいいのか、どんな形式がいいのかといった疑問が次々と出てきます。
WebAPIリクエスト仕様書としてcurlコマンドのご提案 - Qiita
WebAPIの仕様を記述する方法はいくつかあると思う。 普通に日本語で記述する JSON Hyper-Schema、WADL、RAML、Swaggerなどを使う 仕様書の代わりにプログラムを書く HTTPメッセージそのものを記述しておく でも、文法にばらつきがあったり、読みにくかったり、ツールのセットアップが面倒だったり、どれもイマイチな所があって、手軽な方法が欲しいと思っていた。 何気なくcurlコマンドのオプションを調べていたら、「もうこれでAPIドキュメント扱いにしちゃえばいいんじゃね？」と思えてきたのでメモしておく。 curlコマンドのおさらい curlコマンドはlibcurlの付属コマンドで、最近のUnix系OSなら大抵最初から入っていると思う。コマンドの詳細はmanを読んでいただければ。 cURL - How To Use （マニュアルページ日本語訳） curlコマンドのオプシ
全てがJSONになる - ✘╹◡╹✘
TL;DR JSON Schemaを使ってこういうことが実現可能になった。 ダミーAPIサーバの提供 ドキュメントの自動生成 APIクライアントの動的定義 APIサーバのバリデータの動的定義 APIサーバのレスポンスの自動テスト JSON Schemaとは JSON SchemaというのはあるJSONのデータ構造を記述するための方法および書式の仕様で、 JSON SchemaもJSONで記述される。 これを利用すれば、リソースベースの(=RESTfulライクな)APIの仕様が簡便に記述できる。 例えば、我々のAPIはレシピとユーザというリソースを扱っていて、 それぞれCRUDのAPIを備えており、レシピはidとtitleとdescriptionという属性を持つ、 という旨をJSON Schemaで表現できる。 なんで最近ちょっと流行ってんの Mobile First、 Service Or
例えば OSFA な API をやめる - @kyanny's blog
OSFA == one-size-fits-all 単一の API で全てをカバーするのをやめたらどうか、ということ。 APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight @kenn 最近はRESTfulなエンドポイントは完全に後方互換なまま、クライアントごとにオーケストレーション層(radical versionin)を設けるという方向にシフトしようとしている。詳しくは http://t.co/zODm7mFr5B— Tatsuhiko Miyagawa (@miyagawa) February 28, 2014 この話のポイントとはちょっとずれてる && Podcast 聴いてないのですが。 Quipper プラットフォームで内部的に利用されている API も、 /v1 というパスの下にはえててごく一部のエンドポイントだけ /v2 がある、み
Nagios × boundioを使った鬱陶しいアラートの作り方 β
fujya.shです。はじめての人は、はじめまして！そうじゃない人はお久しぶりです。 最近暑いですね。サーバールームの温度も少し上がってきたので、あぁ本当の夏がやってきたんだなと実感できる今日この頃です。 今回はboundioというKDDIウェブコミュニケーションズが提供している電話APIサービスを使って少しもにょもにょしてみたいと思います。 ■アラートメールがジャンジャン来るとむしろ気づかない。じゃあ電話じゃない？ 運用しているサービスが増えてきたり、サーバーの台数が増えてくるとアラートメールがジャンジャンきたりしますよね？本来ならばそういった場合にアラートの原因をすぐさま対策するか、しきい値の変更を実施すれば良いのですが時間的な制約で次週へ持ち越し・・・なんて事も稀にある話です。 そんな時にメールボックスがパンクしてしまい、ほんとうに大事なアラートに気付けない事もあるって話を聞いたり聞
こてさきAjax:マルチデバイス連携を実現する WebIntents 〜基本と使い方編〜 - livedoor Blog（ブログ）
新年明けましておめでとうございます。本年も宜しくお願いします。 さて、今年最初のPOSTは、僕が今一番興味を持っているAPIの "Web Intents" について取り上げます。 この、"Web Intents"は、Androidの "Intent" に非常に良く似た仕組みで、異なるWebアプリケーションを自由に連携することを可能とするAPIです。Webサイトの不足機能に対し、他のWebアプリの機能を利用することが可能になるため、スピーディーなWebアプリの開発を実現してくれます。利用するユーザーにとっても、手慣れたWebアプリを利用できるメリットが有ります。 このAPIの更に興味深いところは、 Device機能の利用 デバイス内の固有の機能（カメラや、住所録など）をブラウザから利用する。 Web of things スマートフォンやテレビなどのマルチデバイス連携サービスをWebで実現する
Twitter 新 API のドキュメント「Getting Started with @Anywhere」日本語訳 - WebOS Goodies
先日行われた Twitter の開発者向けイベント「Chirp」にて、 @Anywhere という新 API が公開されました。自分のサイトに、 JavaScript のみでユーザー情報の表示やつぶやきの投稿、ユーザー認証などの機能を実装できる、とても興味深い API です。 この @Anywhere は使い方も非常に手軽で、こちらのページでサイトを登録すれば、あとは「Getting Started with @Anywhere」にある JavaScript をページに挿入するだけで利用できます。しかし、当然ですが説明は英語ですので、日本人には少しとっつきづらい面もあります。こんな有用な API が日本で普及しないのは大きな損失、ということで前述のページを日本語に翻訳してみました。 勢いで翻訳したので表現はかなり適当ですが、まあ無いよりはましかと思います（笑）。 @Anywhere を利用
Mathematical (TeX) Formulas - Google Chart Tools / Image Charts (aka Chart API) - Google Code
Mathematical (TeX) Formulas This document describes how to use the Chart API to render a mathematical formula on your web page. Table of Contents Overview You can render a formula in a static image file. To do this, you must understand the TeX language (pronounced "tek") in order to specify your formula. TeX formulas have a specific set of parameters that differs from the standard. Here are the
Read Later API
Read Later APIThe Instapaper API allows third-party applications to add URLs to Instapaper. BasicsAll API methods are accessible via very simple HTTP calls. This is optimized for ease of implementation, so you won’t see any XMLRPC, SOAP, or anything containing the word “enterprise”. Simply hit the provided URLs with their respective parameters, and a simple text response is sent. The HTTP status c
ステップ・バイ・ステップで Pathtraq の API を使ってみよう - IT戦記
はじめに 「このサイトの人気ページを見たい！」 「このページに、皆いったいどうやって来てるんだろう？」 「このページを見たあとは、どこを見に行ってるんだろう？」 そんなこと思ったことありませんか？ Pathtraq API を使うことで、そんな情報をあなたのソフトウェア、ウェブアプリケーションに組込めるようになりました！やった！ でも、難しいんでしょ＞＜？ 違うよ。全然違うよ。超簡単だよ。 というわけで、今日は JavaScript から Pathtraq API を使ってみましょう！ Step 1 Pathtraq API を目で見てみよう！ やり方は、簡単です。 http://api.pathtraq.com/pages?url=**ここに調べたい URL** とやるだけです。 試しに、このブログを見てみましょう。 RSS が出力されました。 これは、 IT 戦記内で最近人気のページを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Hatena Developer Center
