こんにちは！乃木坂46の西野七瀬さんと誕生日が同じサーバーサイドエンジニアの@itoshoです。 僕は元々PHPerなのですが、ここ1〜2年くらいRubyを書く機会が多かったこともあり、最近はRubyでいいな！と思った考え方や技術をPHPに輸入することにハマっています。 そこで今日は少し古い記事になるのですが DHHはどのようにRailsのコントローラを書くのか を参考にして、Ruby on Rails（以下Rails）の産みの親であるDHHさんのコントローラーの書き方をCakePHPに取り入れてみたいと思います。 DHHさんのコントローラーの書き方 そこに至るまでの考えなどの詳細は元記事をご覧いただければと思いますが、要約すると、 RESTの原則に従う場合、コントローラはデフォルトのCRUDアクションだけを使い、その他のアクションは新たに専用のコントローラを作成する。 という考え方になり
mozaic.fm #7 RESTや#mozaicfm REST を聴いての感想、それから「Web+DB vol82のWebAPIデザインの鉄則」に触発されたので書こうと思う。 REST設計について WebAPIを設計するうえでRESTが重要であることは周知のとおりである。 “Constraints are liberating”「制約は自由をもたらす」 @t_wadaさんがおっしゃっているように、RESTを前提にすれば、「アーキテクチャとしてもそうだし、アプリケーションフレームワークも「適切な制約」を設けることで設計のコストが下がる」という大きなメリットが生まれる。 しかし、相変わらずリソース設計やらインターフェース設計やらで悩んでおられる方も多いと聞く。 その一方で個人的には適切なフレームワークを使えばREST設計で悩まなくてもよいはず(※3)という思いもある。 インターフェース設計な
2016/10/12 社内勉強会で使ったスライドを社外向けに一部加筆訂正したもの
ここしばらく、REST APIって本当に便利なのか？ という疑問を持ちながらコーディングしてました。 ですが、今の会社に移り、JSON RPCを利用してAPIを叩くうちに「あ、もうこれでええやん」という悟りを得たのでそういう日記を書きます。 RESTful難しくない？ RESTful思想に則って、頭を絞ってリソース階層を練り、urlパラメーターとpostパラメーターに頭を悩ませ、冪等性とはなんぞやという議論をぶちかましながらAPIを作り上げるのに疲れました。 ベストプラクティス的なものも一応読んだりしたんですが、複雑すぎです。 普通のプログラミング言語と、RDBを操作するSQLの間にインピーダンスミスマッチが存在するように、REST APIのcallにも同じものを感じてしまいます。 ここら辺の問題は GraphQL | A query language for your API が解決して
OpenSocial の JSON-RPC, RESTful API の設計についてのよもやま話です。 JSON-RPC とクエリパラメータ OpenSocial Core API Server Specification 1.1 に URL Addression と言うセクションがあります。 これは JSON-RPC を http GET で呼び出す際に params の部分など構造化されたデータをどうやって渡すのって際の仕様になります。 JSON Object URL Parameter { "field" : "value" } field=value { "field" : [1,2,3,4,5]} field=1,2,3,4,5 { "field" : "12" } field='12' { "field" : [identifier,anotheridentifier]} fi
HTTPで通信するAPIはRESTで設計するのが定石ですが、利用者から見ると不便な場合があります。 RESTは設計に強い制約を与えるため、多人数で開発するときでも設計の一貫性を確保することができるのが利点です。更に一定のパターンに従っている分、既存のRESTクライアントを使って手軽にAPIを利用した機能を実装できるのも魅力的です。 しかし設計がRESTに従う分、例えばいくつかの処理をまとめてトランザクションとして扱いたい、といった場合に、インターフェースを独自に拡張しなくてはいけない状況に立たされることがあります。そもそもRESTだとAPIの単位が細かすぎて、利用者から見て使いにくい、といったケースもあります。 そういった場合はRPC（Remote Procedure Call）でAPIを設計することを検討してみても良いかも知れません。RPCの中でもJSON-RPCという仕様が比較的実装し
マイクロソフト、「Excel REST API for Office 365」正式リリース。保存されたExcelのワークシートにAPIでアクセス可能 多くの企業で活用されているExcel。営業部門が各営業担当の進捗状況から売上げを予測するExcelシートを作成していたり、経理部門が経費の配賦をExcelのワークシートで管理してる、などという例も少なくないでしょう。 一般的にこうしたExcelで作り込まれた社内のアプリケーションを既存の業務アプリケーションに組み込むためには、いちどExcelで作り込まれたアプリケーションを解析し、あらためてプログラミング言語で組み立て直す必要がありました。 マイクロソフトが正式にリリースした「Excel REST API for Office 365」を用いると、OneDrive（補足：使えるのはOneDrive for Business）に保存したExce
移転しました http://please-sleep.cou929.nu/20130121.html
新卒でいちばん最初に配属された部署が、ソーシャルゲームプラットフォームのAPIを開発する部署でした。 "れすと"だとか、"れすとふる"だとか、名前が似通ってて何言ってんだこいつ状態だったときのメモ書きを再構成して、Qiitaにまとめておこうと思います。 REST API REpresentational State Transfer の略。(具象的/写実的な状態) RESTの世界ではネットワーク上のコンテンツを一意なURLで表す.(これをRESTfulと表現する) URLに対してGET, POST, PUT, DELETEでリクエストを送信し、レスポンスをXMLやjsonで受け取る. RESTful API パラメータを指定して特定のURLにHTTPでアクセスすると、 XMLで記述されたメッセージが送られてくるシステム(または呼び出しインターフェース)を指す. SOAP API Simpl
小文字のみを使用する。 単語をつなげる必要がある場合はダッシュを利用する。 単数形よりも複数形をつかう。なお、実装がRailsの場合でテーブルの複数形が誤っている場合には、URLは正しい複数形としてRails側を修正する。（APIに実装を反映させるべきではない。） スペルミスをしない。 URLの階層は浅く保ち、複雑さはクエリパラメーターに押しこむ。 クエリパラメータ名は配列で複数渡すものについては複数形、一つだけ渡すものについては単数形とする。 ページングにはper_page、pageというパラメータ名を使用する。 と書いてきたが、ただし、RESTには必ずしもこだわらず、あくまで利用側の利便性を重要視した設計とする。 1つの作業を完結するために複数回のアクセスを必要とするようなAPIの設計はChatty APIと呼ばれる。これはネットワークのトラフィックを増加させ、クライアントの処理の手間
Restfulな設計を個人的にまとめる。 あくまで個人的なまとめで個人的にどこからでも参照できるようにここに張る。 正しいとか間違ってるとかどうでもいいし、参考にするしないは個人で判断して。 基本方針 Restful APIの設計は基本的に以下。 処理の内容 HTTPメソッド URL リソースデータを全て取得する GET ~/api/resources idと一致するリソースを一件取得する GET ~/api/resources/{id} idと一致するリソースを一件更新する PUT ~/api/resources/{id} リソースを一件登録する POST ~/api/resources idと一致するリソースを一件削除する DELETE ~/api/resources/{id} リソースの利用可能なメソッドとパラメータを返す OPTIONS ~/api/resources URL中の「
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 切ない思い出 少し前だけれど、ASP.NET Web APIを使って開発をした。 開発要件からすると大変いい感じにフレームワーク選定したと思うし、急に決めた割には、今思っても良かったと思う選択だった。 ただいざクライアントに提供する機能を作ってるうちに、なんか変なことになってきた。 とりあえずPOST クライアントからDBに対して読み書きしたい用事があるときは当然Webサーバーで、ASP.NET Web APIで作った機能を経由することにした。ただその時に、DBのテーブル（単体）に対するCRUDだったらテーブルからScaffoldした処
RESTful WebサービスではHTTPステータスコード=処理結果 弊社 アイコン認証Webサービス は、REST方式のWebサービスとして実装されています。 REST方式でない通常のWebアプリケーションでは、通常HTTPステータスコードとしては200(OK)しか返されません。 エラー等の状態を表す場合でもHTTPステータスは200(OK)が返され、画面に表示される内容にエラーを表すメッセージ等を含ませる事によって状態を表現します。 RESTfulなWebサービスを実現する場合には、処理結果はHTTPステータスコードで表現するべきとされています。 理由としては、以下のものがあげられます。 適切なHTTPステータスコードを返さない ( 全部 200 (OK) とかの ) 場合、エンティティの中身を解析しなければ、処理結果が判別できない。 Web標準に従う事で、HTTPステータスコードから
いまとあるアプリケーションの Web API を設計しているのだが、思った以上にいろいろたいへん。 当たり前だが、APIをただ使うのに比べると10倍以上考えなければならないことがある。 そこである勉強会で教えてもらったのは、「Github API を真似すればいいんじゃね？」という話。調べてみると、すごくシンプルで使いやすい印象。リンクがふんだんにつかわれていて、ハイパーメディアっぽいし。 GitHub API v3 GitHub API が数ある Web API のなかでどのようなポジションにあるのかは寡聞にして知らない。だけど、かなりイケテル部類なのではないか？なにせ、天下の GitHub である。世界のあらゆる優秀なITエンジニアたちの目に毎日触れているのである。おかしな設計の API なんて怖くて晒せないはずだ。ということは、GitHub API をパクって参考にして、Web AP
RESTful な設計って、ってマスタメンテ作るにはいいけどまともなサービス作れるの? という疑問に対して、結構やればアプリケーションできるので安心してください、という話をしました。 「独自研究」セクション以外はだいたいふつうに経験したことです。「独自研究」セクションはたぶん、今流行りのオーケストレイションレイヤをどうするかというところになるのかな、と。APIといいつつ、HTMLを返す話ばかりですが、これはAPIとHTMLをあえて区別せずそれは単にリプレゼンテーションが違うだけです、という意図でした。 転職してから初の社外発表が前職オフィスでやるというのが面白かったです。永和メンバーも結構たくさん会えてよかった。来てくださった方、開催をアレンジしてくださった方、ありがとうございました。
Herokuが自ら実践しているAPIデザインガイドをGithubに公開した． “HTTP API Design Guide” このガイドは些細なデザイン上の議論を避けて，ビジネスロジックに集中すること目的としている．Heroku特有なものではなく，一般にも十分適用できる知見となっている． 最近は，モバイル向けにAPIをつくることも多いため，勉強もかねて抄訳した．なお内容は，HTTP+JSONのAPIについて基本的な知識があることが前提となっている． 適切なステータスコードを返す それぞれのレスポンスは適切なHTTPステータスコード返すこと．例えば，“成功"を示すステータスコードは以下に従う． 200: GETやDELETE，PATCHリクエストが成功し，同時に処理が完了した場合 201: POSTリクエストが成功し，同時に処理が完了した場合 202: POSTやDELETE，PATCHリク
現在ではREST APIはとても一般的な話題です。ほとんどすべてのWebアプリケーションの一部分となっています。シンプルで一貫性があり実際的なインターフェースは必須です。これは皆さんのAPIを他の人が使うことをとても容易にします。皆さんにとってはRESTの実践が日常的に感じられるかもしれませんが、RESTをあまり尊重しない人々もよく見かけます。これがRESTについて投稿するきっかけでした。 この記事にはRESTfulなAPIを設計する時に考慮すべきベストプラクティスがあります。 注意 : ここでのベストプラクティスは、私が過去の経験に基づいて良いと考える事例です。もし違う考えをお持ちであれば、お気軽にメールをくだされば意見交換できると思います。 APIのバージョンを示す APIのバージョンは必須であるべきです。これがあると時間が経ってAPIが変わっても影響を受けません。その方法の1つはUR
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く