小文字のみを使用する。 単語をつなげる必要がある場合はダッシュを利用する。 単数形よりも複数形をつかう。なお、実装がRailsの場合でテーブルの複数形が誤っている場合には、URLは正しい複数形としてRails側を修正する。(APIに実装を反映させるべきではない。) スペルミスをしない。 URLの階層は浅く保ち、複雑さはクエリパラメーターに押しこむ。 クエリパラメータ名は配列で複数渡すものについては複数形、一つだけ渡すものについては単数形とする。 ページングにはper_page、pageというパラメータ名を使用する。 と書いてきたが、ただし、RESTには必ずしもこだわらず、あくまで利用側の利便性を重要視した設計とする。 1つの作業を完結するために複数回のアクセスを必要とするようなAPIの設計はChatty APIと呼ばれる。これはネットワークのトラフィックを増加させ、クライアントの処理の手間
「翻訳: WebAPI 設計のベストプラクティス」を読んで色々と思うところがあったので書きました。 上記の記事は訳文でありますので、正しくは「Best Practices for Designing a Pragmatic RESTful API」に対する所感と述べた方が良いのかもしれませんが、日本語で通して読めるよう Qiita に投稿された訳文に対する所感として書いています。 以下では「翻訳: WebAPI 設計のベストプラクティス」並びに「Best Practices for Designing a Pragmatic RESTful API」は「当該記事」と表現します。 観点 当該記事では「○○とした方がよい」との意見に対してそうすべき理由が明らかになっていないか、もしくは表現が曖昧な場合が目立っていると感じました。設計は実装のようにプログラム言語仕様が制約を与えられないため、意図
これは Enchant の開発者である Vinay Sahni さんが書いた記事「Best Practices for Designing a Pragmatic RESTful API」1を、ご本人の許可を得て翻訳したものです。 RESTful な WebAPI を設計しようとすると、細かなところで長考したり議論したりすると思います。また、他の API に倣ってやってはみたものの、本当にそれでいいのか、どうしてそうしているのか分からない、何てことも少なくはないと思います。 この記事では、そのようなハマリどころについて Vinay さんなりの答えを提示し、簡潔かつ明快に解説してくれています。 今後 WebAPI を設計される方は、是非参考にしてみてください。 なお、誤訳がありましたら編集リクエストを頂けると幸いです。 まえがき アプリケーションの開発が進むにつれて、その WebAPI を公
◯ リソースを一意に識別 RESTな考え方では、すべてのリソースはURIで表されるユニークなアドレスを持つ。 ◯ ハイパーメディア(リンクのこと)を仕様 今では結構当たり前。パソコンのOSに保存された設定情報に依存せずにリソースにリクエストすること。つまり、どのパソコンでも同じレスポンスが返ってくるリンクをHTMLとかXMLに含める。 ※ クッキーとセッションを用いたアプリケーションはRESTではない。 クッキーとセッションの仕組み RESTはあくまで、固有のHTTPメッセージ(リクエスト/レスポンス)に対して、固有の表現を表示する。つまり、クライアント側はサーバーからのレスポンスをただ一意に読みこめば良い。逆にサーバー側もただ、クライアント側のリクエストを一意に返せば良い。しかし、クッキーとセッションの仕組みは、クライアント側(ブラウザ)にアクセスするためのクッキーを一時的に保存させてあ
今度は「Rails3 失敗から学ぶDevise利用時のURL設計 - 130単位」のコメントをきっかけに考えてみました。 routes.rbの書き換え 新規登録のときに確認画面や完了画面がほしいという場合はよくあります。 もともと match 'user_entry/profile' match 'user_entry/setting' post 'user_entry/confirm' post 'user_entry/create' get 'user_entry/complete' だったものを、 resource :user, :only => :show do resource :profile, :except => [:show, :destroy] resource :setting, :except => [:show, :destroy] end とするのはどうか、と考
【画像】 セーラー戦士を黒人化した黒人絵師に海外で批判殺到中 1 名前:金星(東京都) [CN]:2019/12/04(水) 21:20:46.35 ID:hXDt62td0 黒人絵師が描いたセーラームーンのファンアートが話題になっていました。日本人絵師が褐色肌のゲームキャラを色白に描いて海外の黒人たちが怒る騒ぎがありましたが、今回は逆に黒人絵師が日本人キャラを色黒に描いてダブルスタンダードだと騒ぎになっているようです。そんな西洋化されたセーラームーンに、海外からはさまざまな意見が寄せられていました。 ・これに皆怒ってるんだけど。 ↑知ってるw気にしないけど。こういうものがシビアなのは分かるけどね。私は多様性が好きなだけだから。 ↑それは理解できるけど、多様性を持った独自のセーラー戦士たちを作ればいいのに。 すべてのキャラを侮辱して塗り替えるんじゃなくて。 ↑これはファンアートだから。スレ
HPのSSD、稼働32768時間で全データ喪失するバグ、復旧も不可。世界中のサーバーが次々死亡しパニック 1 名前:水メーザー天体(北海道) [RU]:2019/12/04(水) 14:03:57.99 ID:ztiKzBZr0 Hewlett Packard Enterprise(HPE)が11月29日に公開したサポート文書によれば、同社のサーバーやストレージ製品に使われている特定のSAS SSDにおいて、稼働時間が32,768時間を超えると、復旧が不可になる深刻な不具合が発生するとした。 HPEによると、SSD製造業者から特定のSAS SSDモデルのファームウェア障害についての通知を受けたという。これらのSSDは、ProLiant、Synergy、Apollo、JBOD D3xxx/D6xxx/D8xxx、MSA、StoreVirtual 4335/3200といった多くのHPE製サーバ
NTTデータ子会社のクラウドが壊滅、ストレージのバグで戸籍や税務などのデータ全消失 1 名前:ベスタ(茸) [US]:2019/12/05(木) 17:18:57.47 ID:yztuQHN80 日本電子計算株式会社(通称:JIP)とは、NTTデータの子会社、いわゆる「デー子」である。 概要 1962年に日本証券金融株式会社の電算室が独立し「日本電子計算」として分社化するかたちで設立された。 2012年にNTTデータにより公開買付(TOB)が行われ約100億円で買収された。 この買収は「NTTデータは銀行業には強いが証券業には弱い」というのを補うためだとしている。 2019年12月4日午前11時ごろ、同社が運営するクラウドサービスが吹っ飛び、その上で動く全国の自治体システムも吹っ飛び、全国約50の自治体で戸籍管理や税務処理、医療保険、図書館などのデータが消失した。 2019年12月4日午後
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く