RESTfulなWeb APIを設計するときに考えること - Qiita
ApigeeやHerokuのドキュメントに従うのでもよかったんだけど、読んでいく中でやっぱり考えることは出てきたので、あくまで自分のための指針をまとめてます。 包括的なWeb API作成についての知見 HerokuのAPIデザイン | SOTA interagent/http-api-design · GitHub Web API 設計のベストプラクティス集 "Web API Design - Crafting Interfaces that Developers Love" - フリーフォーム フリークアウト Web API Design | Apigee NetFlixもWeb APIの設計についての知見をよく放出してくれてる印象。 設計の基本 基本は /コレクション/名詞 リソースの関係を表したい時に階層化する members/1234/friends 階層は浅く保つ できるだけ/c
apigeeのWeb API Designよんだ
なるほど URLには複数形の名詞で具体的な名前をつけましょうね 大抵の人がおそらく使うであろうRESTful APIはGETメソッドだろうとのことでURLの名称は複数形の名詞にしておくのが自然。 ただし、複数のリソースを含んでしまうような名前は避けないとダメ。 それから、/itemsとか/assetsみたいな抽象的な名称も避けないといけない。/itemsというリソースにはおそらくブログや動画が含まれうるから。 関連性はシンプルに リソースはほとんどの場合が別のリソースと関連している。では、そういう時どうやってシンプルさを保つか。 犬には飼い主がいるだろう。なので次のようにできる。 GET /owners/5678/dogs POST /owners/5678/dogs こんな風にしていくといくらでもリソースの階層が深くできてしまう。 そこで知っておきたいのは主キーが決まってしまえば情報は特
JupyterでScheme処理系を動かしてSICPを勉強する | DevelopersIO
はじめに 最近社内でSICPの勉強会を行っています。 SICPでは、教材としてLISP処理系の一つであるschemeを採用しており、勉強する時にはschemeを動かしながら例題の動作確認や課題を行っていきます。 Emacs + Gaucheを用いて学習を進めていくパターンが多い印象ですが、Emacsに慣れていない人にとっては、まずEmacsの操作を満足にできるようになるまでに高いハードルがあります。 今回は、Emacsの代わりにJupyterを用いてScheme処理系を動かし、その動作を確認する方法を紹介します。 Jupyterについて Jupyterとは、簡単にいってしまうとブラウザ上で動作するREPL環境 + メモ帳です。 以下の画面のように、コードをその場で実行し、その結果をその場で見ることができます。 また、コードの他にmarkdown形式で文章を追加することもできるので、コードと
ドリコムを退職しました……弟子が | 外道父の匠
世間の流れに沿って、一度、退職エントリを書いてみたかったんですけど、まだちょっと退職しそうにないんで、倒置法で我慢してみました。 本人には「退職エントリ書くね！」と去り際に伝えてありますが、センシティブなカテゴリですから、企業・個人事情に基づくものというよりは、身近な人間が退職したという出来事に対する感想的なものとなります。 ザッと振り返って 前に書いた、「新卒インフラエンジニアを育成した話」で地獄を見せようと試みて、いまいち業火で焼き尽くせず耐え切ったアノ弟子です。二年が経過し、中小規模のサービスを専任で4～5個担当するまで至っていたので、当人の努力と成果は十分であったのかと思います。 他にも、AWS関連や、インフラのアーキテクチャなどは、私と共に進めたり、時には率先して案を出したりもしてくれていたので、中盤からは弟子というよりは普通に共同作業者という立ち位置でした。例えば「現代ITイン
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
