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
RESTful API Versioning, though a simple and elegant concept, is a LOT harder to enforce than it sounds. It’s hard to not break backward compatibility on a continually evolving API, and though API versioning is a great concept, it’s rarely followed without flaw. There’s a reason why throngs are flocking toward intermediaries like GraphQL. RESTful API idealism crashes apps. You know it. Have you toi
AndroidでAPIとやり取りする場合、HttpURLConnectionとか使ってスクラッチで書いてもいいんですが、ライブラリを使ったほうが簡単に書けます。 そのような便利ライブラリの１つにAndroidQueryというのがあります。名前からわかるとおりjQueryに影響を受けており、メソッドチェーンを使って簡単にGET・POSTを実装できます。 僕ももともとAndroidQueryを使っていたんですが、今回Retforitというライブラリに置き換えたところコード量も減りとてもいい感じだったのでメモしておきます。 （１）Before After まずはBefore Afterから。 [Before: AndroidQuery] private void loadUsers() { final AjaxCallback cb = new AjaxCallback() { @Overrid
grpc-gateway という gRPC からJSON APIへの変換プロキシ生成機を書いた。 これを使えばシステム内部ののmicroservicesはgRPCで通信しつつ公開APIはJSON APIで提供する、みたいなことが簡単になる。 なお、gRPCそのものについては mattnさんの記事 が参考になる。 背景 gRPCの良い点はいくつもある。 データはデフォルトでprotocol buffersで直列化される。ベストではないにせよ十分にコンパクト且つ高速だし、サイズで言えばJSONとは比べるべくもない。 簡単に複数の言語でサーバーのテンプレートやクライアントを生成できる。通信の詳細はgRPCにまかせて開発者はサーバーロジックの実装に注力できる。 design by Googleという安心感。 gRPCの素晴らしさは認めるものの、一方では欠点もある。まず、クライアントライブラリの多く
VAddyはCIツールと連携し、継続的なセキュリティテストを実現するクラウド型Web脆弱性検査ツールです。 最近のモバイルアプリケーションやシングルページアプリケーションのような構成ですと、APIサーバに対してPOST/PUTリクエストを送信する際に、パラメータはJSON形式というのも多くなりました。 今回、このJSON形式の場合でも、JSONデータに含まれるパラメータに対してSQLインジェクションの検査ができるようになりました。 これにて、Angular.jsやBackbone.js、iOSやAndroidアプリケーションと通信するAPIサーバ側の検査が可能となりました。 実はAPIサーバのJSONデータの検査対応はそれほど優先度が高くなかったのですが、VAddyミートアップを通してユーザからの要望を頂いた結果、優先すべき項目となり、すぐに実装してリリースとなりました。 このようにVAd
REST API用のドキュメントを生成するときにどうやってるかについて雑記を残しとく。 概要 実装とドキュメントの乖離を避けるためには、同じ意味情報を二箇所以上に定義することを避ける必要がある。そのための方法として、実装それ自身か、もしくは実装が参照している何らかのメタデータを元にしてドキュメントを生成したり、テストの実行結果からドキュメントを生成するというパターンがある。 テストから Cookpadでは、autodocというライブラリを利用して、RSpecでテストを実行している途中で得られたメタデータからドキュメントを生成している。これはテストの実行結果からドキュメントを生成するパターン。 これは実現方法としてはかなり特殊な部類。このパターンが最も効果的に働くのは、ドキュメント生成のために余分な開発コストはあまり掛けたくないが、テストは真面目に書いている OR 真面目に書いてほしい、とい
内部用APIであるか外部の開発者向けのAPIであるかに関わらず、ドキュメントと実装との乖離は極力避けたいものであるが、注意深く開発を進めない限りこの状況は容易に起こり得る。何が乖離を引き起こし、どうすればこの状況を回避できるのか考えながら、JSON Schemaの利用例を紹介する。なおこの投稿では、HTTP経由でデータの通信を行うような狭義のAPIのことをAPIと呼ぶことにする。 同じ情報源を参照する APIドキュメントと実装が同じ情報源を参照するようにすれば、論理的に関連した要素は統一的に変更され、これらの変更は完全に同期が取れたものになる。つまり、変更時に乖離が生じにくくなる。但し情報の見せ方によって乖離が発生する可能性は十分にだろうし、乖離が発生するのは理解しようとする側の認識の問題であるから、論理的に全く起こり得ないということではない。 この参照の形には、両者が別の情報源を参照する
http://corner.squareup.com/2014/09/squares-api.html 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約2時間前 SOAにおけるサービス間のコミュニケーションについては、CODE CLIMATEにおいて、Protocol Buffers vs JSONという比較が取り上げられていて、「ブラウザやJavaScriptが直接データを利用しないケース、特に内部サービス間のコミュニケーションにはProtocol Buffersの方が向いているのでは。」と紹介されています。 せっかく整合性のあるデータ構造を用意しても、サービス間のデータのやり取りの際に苦労させられることが多い。Protocol BuffersならProtoフォーマットにしてエンコーディングするだけで、意図す
シングルページアプリケーションやモバイルアプリなどの普及により、サーバサイドではJSONを出力するWeb APIの必要性が高くなってきています。みなさんはどのようにWeb APIを作っているでしょうか。 JSONはビュー RailsでJSON APIを定義する時、素のままでやろうとすると コントーラでto_jsonを呼んだり、モデルにas_jsonを定義したりすることになるかと思います。 モデルに書くとAPIによって出力内容を変えたい場合にとても苦労します。 API数が増えれば増えるほどモデルが複雑になっていきます。 APIレスポンスとしてのJSONはコントローラやモデルに書くべきでしょうか？ ビューに書いた方が自然ではないでしょうか？ これはRailsでの話ですが、Railsに限らず、フレームワークを使ってWeb APIを作るときに一般的にあてはまることだと思います。 変化に強い、再利用
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
その文字列検索、std::string::findだけで大丈夫ですか？【Sapporo.cpp 第8回勉強会（2014.12.27）】
2014年に向けた JSON API の実装の方向性と X-JSON-Status 改め X-API-Status header のご提案 追記 2014/11/20 14:00:00 わりと JSON やら XML やら各種フォーマットで API を運用している環境がある場合に JSON API の時だけ X-JSON-Status にすると XML とかの時と整合性取れないし、 X-XML-Status みたいのを量産するのは困る的なレビューを頂いたので X-JSON-Status をやめて X-API-Status にしました。 へたに JSON に限定するから REST とか JSON-RPC とかいわれるんや！ X-API-Status にしたら全部解決したし MessagePack な API でも使い回せるって songmu さん言ってた！ XML とかからどうやって引っこ抜
これApigee | Google Cloud Blogの勝手訳のつづき。 「クライアントがサポートするHTTPメソッドが制限されているとき」ですが、GETは冪等じゃなきゃいけないし、少なくともPOSTだろと思うのですが、GETしかできないクライアントを想定しているのかな。 例外的な振る舞いの取扱いのTips これまでのところ、ベースラインつまり標準的な振る舞いを取り扱ってきました。 ここでは、発生しうる例外のいくつかを調査するつもりです。Web APIのクライアントがいままで議論してきたことのすべてを取り扱うことができないときには、例外が発生します。たとえば、HTTPのエラーコードを横取りしてしまうクライアントがありますし、制限されたHTTPメソッドしかサポートしないクライアントもあるでしょう。 このような状況を取り扱うには、どんな方法があるしょうか？そして、特定のクライアントの制限のな
これApigee | Google Cloud Blogの勝手訳のつづき。 属性の名前をどうするか 直前のセクションでは、フォーマットについて述べました。複数のフォーマットをサポートし、JSONを既定のフォーマットとして動作することを推奨しました。 こんどは、レスポンスを返すときに何が起こるのかを述べましょう。 データ属性をもったオブジェクトがあります。属性にどのように名前をつければよいのでしょうか? 主要なAPIからのAPIレスポンスをいくつか挙げます。 Twitter "created_at": "Thu Nov 03 05:19;38 +0000 2011": Bing "DateTime": "2011-10-29T09:35:00Z" Foursquare "createdAt": 1320296464 それぞれに異なったコード変換をつかっています。TwitterのアプローチはR
HTTPでアクセスして、JSONを返すようなWebサーバを書きたいとする。 どんな言語を選ぶか。どんなミドルウェアを選ぶか。どんなライブラリを選ぶか。 たとえば、TIOBE Softwareが公表している「Programming Community Index(PCI)」という指標がある。人気のあるプログラミング言語の数値化。これを見ていて思ったのは、「多すぎだよね、プログラミング言語」ということ。これらのうち、どの言語を勉強し、どの言語をプロジェクトに採用すべきなのか。 その感触を得るために、 「同じ仕様のREST serviceを複数言語で実装したらいいんじゃね？」 と思った。いくつかの言語で実装を起こしてみている。 前提条件 大規模な開発を想定する。ユーザの規模が大規模。トランザクション数が大規模。そして、開発者が大規模。 実用的かつモダンな開発を想定する。プロジェクト毎のバージョン
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
