Mapboxは、様々な情報を集約し自由自在な地図描画を行うことで ロケーションデータの活用を推進する地図開発プラットフォームです。 Mapboxは、様々な情報を集約し 自由自在な地図描画を行うことで ロケーションデータの活用を推進する 地図開発プラットフォームです。
はじめに モチベーション 異なるエンドポイントで、大体似たようなレスポンスなのに、 キー名が違う... キーが多かったり少なかったりする。。 というような、Web API (主にjsonを返す) を作っていてよく問題になる現象。 このような問題に対してのアプローチとしてはいくつかある。 例えば、formatする関数を用意して、必ずレスポンス返却前にそれを呼んで返す、のような運用的な解決手段。 が、 あまり強制力がない 宣言的ではなくどうしても手続きっぽくなる というところで、ややイケてなさが残る。 そこで、API全体としてもっと強力な制約を課し、宣言的にやることで、レスポンスの形を完全に安定させたい。 そのために導入したのが、 (厳密な)リソース指向API と呼んでいるもの。 それ自体は何の新規性もないのだが、2ヶ月くらい運用してみて割と上手く行っているので、その気持ちと実装のことを書く。
ちょっと前にTwitterでAPIのバージョニングをどうやるかみたいな話をしていたのですが、そのへんもやもやしているので少し整理しておきたいなと。 APIのURLを/api/v1/*とかってやるの、やめたほうがいいとおもうんだけどなぁ。いざv2を作るとなったときに、大量のコピペが発生して後悔するよ、って伝えたい。— Kenn Ejima (@kenn) February 28, 2014 さて、これについて色々と異論・反論も含めた意見が出たのですが、まずは、大昔にURL方式(=コントローラ分割)でやってきて後悔したぼくが、(5年ぐらい前から)現在はどうやってAPIのバージョンを管理しているか?について紹介します。 基本原理としては、コピペが多発する根っこで分岐(=コントローラ分割)じゃなくて、必要最小限のところで限局的に分岐するのがいい、という考え方に基づきます。 一言でいうと、「パラメー
みなさん、今年の2月末にGoogleが発表したgRPCをご存知でしょうか?gRPCとは、こちらも今年の5月にRFCとして公開されたばかりのHTTP/2を標準でサポートした新しいRPCフレームワークであり、効率的で拡張性の高いAPIや最近流行のマイクロサービスの作成をサポートします。本記事では、Goでのサンプルアプリケーションの作成を通してこのgRPCの通信を試してみようと思います。 gRPCの概要 図1.gRPCの全体像(http://www.grpc.io/docs/より転載) gRPCのサーバーとクライアントはお互いに様々な環境(Google内部のサーバーから、各自のデスクトップ環境まで)で通信でき、gRPCがサポートしている言語(C++, Java, Go, Python, Ruby, Node.js, Android Java, C#, Objective-C, PHP)で書くこと
In my previous post, I went through the paces of creating a JSON Schema to describe the JSON that my service will accept and return. The process leans on the prmd gem to supply the initial JSON Schema templates, as well as validation and document generation. All in all, it’s a process that feels like it should be more automated. I went through a fair amount of pain to get the schema created, manua
概要 Webアプリケーションを開発しているとしばしば、APIサーバ側がクライアントのことを考えたレスポンスを返すことを意識した結果、いろいろと辛い状態になることがある。このような状態をいかに解消していくかを考察していく。 本稿で想定するWebアプリケーション サーバサイドはWeb API (大抵はHTTP, JSON)であり、iOSアプリ、Androidアプリ、ブラウザアプリ(Single Page Application=SPA)があるような、一般的なWebアプリケーションを考える。 開発の流れは、まず仕様が提案され、それをもとに、iOS/Android/Browserでの画面仕様が作られる。それを見ながら、アプリのエンジニアとサーバサイドのエンジニアが打ち合わせ、APIのエンドポイント・リクエスト・レスポンスの型を定め、その後お互いに開発を開始する。 Smart UI アンチパターン
1 Overview JSON-RPC is a stateless, light-weight remote procedure call (RPC) protocol. Primarily this specification defines several data structures and the rules around their processing. It is transport agnostic in that the concepts can be used within the same process, over sockets, over http, or in many various message passing environments. It uses JSON (RFC 4627) as data format. It is designed t
HTTPで通信するAPIはRESTで設計するのが定石ですが、利用者から見ると不便な場合があります。 RESTは設計に強い制約を与えるため、多人数で開発するときでも設計の一貫性を確保することができるのが利点です。更に一定のパターンに従っている分、既存のRESTクライアントを使って手軽にAPIを利用した機能を実装できるのも魅力的です。 しかし設計がRESTに従う分、例えばいくつかの処理をまとめてトランザクションとして扱いたい、といった場合に、インターフェースを独自に拡張しなくてはいけない状況に立たされることがあります。そもそもRESTだとAPIの単位が細かすぎて、利用者から見て使いにくい、といったケースもあります。 そういった場合はRPC(Remote Procedure Call)でAPIを設計することを検討してみても良いかも知れません。RPCの中でもJSON-RPCという仕様が比較的実装し
Ruby Business User Conference 2015での発表資料です。
HTTP API Design Guide This guide describes a set of HTTP+JSON API design practices, originally extracted from work on the Heroku Platform API. This guide informs additions to that API and also guides new internal APIs at Heroku. We hope it’s also of interest to API designers outside of Heroku. Our goals here are consistency and focusing on business logic while avoiding design bikeshedding. We’re l
最近のウェブ開発では各機能ごとをAPIでつなぎ込む時代になっています。 そのため、各チームが開発をしていく上で、 他のチームにAPIの仕様を伝える方法をきちんとまとめておく必要が出てきています。 そんな中でAPIドキュメントにどのような役割が求められていて どのような選択肢があるか、一旦自分の把握している知識をまとめています。 (ここで書いているAPIは、httpでアクセスしたら、JSON形式でレスポンスを返すウェブサービスのAPIを指しています) APIドキュメントを用意する上で、すぐにぶつかる壁 APIドキュメントを用意する場合に、何も考えずにExcelやwikiにまとめると、早い段階で メンテナンスのコスト の問題にぶつかります。 『APIドキュメントを書く時間がない』 『本当にドキュメント通りの結果が返ってくるか、試してみないとわからない』 『実際に返ってくるAPIとレスポンスが違
JSONスキーマと、RubyでJSONスキーマつかってvalidationするやり方を解説します。 全てがJSONになる - ✘╹◡╹✘ を読んでJSON schema良さ気だと思ったけど、まだ使ったことない人向けの記事です。 JSONスキーマって? 本屋のJSONデータを返すAPIがあったとします。 { "name": "おしゃれな本屋", "place": { "large_area": "おしゃれな地域", "small_area": "おしゃれな街", "address": "おしゃれな街のおしゃれな建物", "latitude": 33.333, "longitude": 33.333 } } これに対して、JSONスキーマを用意しておけば、1つ1つの値の有無や型をチェックできます。生成したJSONが意図したものになっているかテストするのに便利です。 JSONスキーマといいつつJ
Visaが決済サービスなどのAPIをオープンに提供、開発者向けプログラムを開始:デジタル決済を促進 米Visaは2016年2月4日(米国時間)、同社の提供する各種サービスをアプリケーションから直接利用できるAPIを包括的に提供する開発者向けプログラム、「VISA Developer」を提供開始した。 クレジットカード/デビットカードを中心とした決済ネットワークサービスを展開する米Visaは2016年2月4日(米国時間)、同社の提供する各種サービスをアプリケーションから直接利用できるAPIを包括的に提供する開発者向けプログラム、「VISA Developer」を提供開始した。 Visa CEOのチャーリー・シャーフ(Charlie Sharf)氏は発表イベントで、「当社のプラットフォームを開かれたものにすることで、数え切れないほどの数の開発者に、スキルや創造性、知恵を生かしてもらうことができ
ご指定いただいたページは、現在URL(アドレス)が存在しないようです。 恐れ入りますが、トップページより再度画面をご確認いただきますようお願いいたします。
目次 概要 前提知識 J-SHIS Map APIサービス – 情報提供サービス – 情報検索サービス J-SHIS Labs APIサービス – 情報提供サービス URLビルダー 概要 J-SHIS Web APIは、J-SHIS MapおよびJ-SHIS Labsで表示している情報をメッシュ形状とともに取得することができるWeb APIです。 J-SHIS Web APIを利用すると、独自に作成したウェブページで地震ハザード情報、表層地盤データなどを表示したり、モバイル端末上で現在位置のメッシュに影響の大きい地震断層を検索するアプリケーションなどを作成することができます。 レスポンスのデータフォーマットは表に示すように2種類あります。 フォーマット レスポンス
※ この記事はMOONGIFTレポートにて2008年10月に記述した内容を多少修正したものです 今回はWeb APIの抱える問題点や今後のあるべき姿について書いておこうと思います。 私自身は2008年3月までWeb API、MashupのポータルサイトであるMashupediaを運営してきました。その辺りの事情から言うと、日本においてWeb APIのあり方はなんともし難い状態になっていると言えます。理由は幾つかあるのですが、 1. ビジネスモデルがない 2. 基になるWebサービスありきである 3. 基になるWebサービスが魅力的でない に集約されると考えています。詳細は以下にて。 1.についてはWeb APIの公開がパブリッシング目的であったり時流に乗ったケースで見られます。そのため、初期のパブリッシングが達成されてしまうと、その価値が低減し、追加開発も行われなくなります。また、Web
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く