[B! reST] masudaKのブックマーク

gRPC and REST with gRPC in practice

go-sqlite3を使ってCloud Spannerエミュレーターを作ってみた / Cloud Spanner emulator with go-sqlite3

masudaK 2017/07/14

gRPC
reST

リンク

REST clientのPostmanが便利だった - 偏った言語信者の垂れ流し

PostmanはChrome拡張のREST client。 Postman | Supercharge your API workflow ChromeWebStoreからインストールできる。リクエストの履歴が保持されて再利用できるので、気軽に複数種類のリクエストを叩けるのが楽。また、リクエスト内容をCollectionにまとめておけば、Import/Exportできるので、チームの他の人と共有するのが簡単なのも良い。開発やら試験がはかどる。

masudaK 2014/05/11

reST
chrome

リンク

《REST思想》と《リソース指向》と《Webページ》に関する（主にRailsの）話 - Qiita

これはいわゆるWeb APIについて、ということかなと推測しました。RESTというのはAPIのプロトコルのことだと思われている傾向がありますが、そういうわけではありません。Web全体についてのもので、APIについてもWebアプリについても適用されるものです。実はRESTでは「統一インターフェイス」の制約からメソッドについて規定されていますが、URLの形については特に規定されません（もちろんAddressabilityの面で重要であることは言うまでもありません）。なので実は/books,/books/1でなくてもいいのですが、これを規約(CoC)でズバッときれいに決めてしまったのがRailsのすごいところの1つです。本の追加や削除を行う場合は、本情報をJSON形式でPOSTリクエストのボディとして送ります。application/x-www-form-urlencoded形式で送ることは

masudaK 2014/03/24

reST

リンク

拡張可能なWeb APIの設計原則と、バージョン番号を使う理由について

APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sightにはブコメしたのですが、Rebuild: 35: You Don't Need API Version 2 (Kenn Ejima)でも本件に言及があったようなので、少し一般論を書いておきたいと思います。 ■Web APIの設計原則についてそもそも、良いAPIとはどのような特性をもつものでしょうか？　一般的に、以下の２点が挙げられると思います。拡張が容易である拡張時に後方互換性を破壊しないウェブの場合は、これに加え、スケーラブルである HTTPに起因する問題に上手に対処できることが求められます。前２者はウェブに限らない要件です。これを満たす設計手法としては、リクエストおよびレスポンスのパラメータを拡張可能に互換性を壊す拡張が必要な場合は、関数名を変える古い関数は従来と同じ機能を

masudaK 2014/03/10

リンク

APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight

ちょっと前にTwitterでAPIのバージョニングをどうやるかみたいな話をしていたのですが、そのへんもやもやしているので少し整理しておきたいなと。 APIのURLを/api/v1/*とかってやるの、やめたほうがいいとおもうんだけどなぁ。いざv2を作るとなったときに、大量のコピペが発生して後悔するよ、って伝えたい。— Kenn Ejima (@kenn) February 28, 2014 さて、これについて色々と異論・反論も含めた意見が出たのですが、まずは、大昔にURL方式（＝コントローラ分割）でやってきて後悔したぼくが、（5年ぐらい前から）現在はどうやってAPIのバージョンを管理しているか？について紹介します。基本原理としては、コピペが多発する根っこで分岐（＝コントローラ分割）じゃなくて、必要最小限のところで限局的に分岐するのがいい、という考え方に基づきます。一言でいうと、「パラメー