翻訳: WebAPI 設計のベストプラクティス - Qiita
これは Enchant の開発者である Vinay Sahni さんが書いた記事「Best Practices for Designing a Pragmatic RESTful API」1を、ご本人の許可を得て翻訳したものです。 RESTful な WebAPI を設計しようとすると、細かなところで長考したり議論したりすると思います。また、他の API に倣ってやってはみたものの、本当にそれでいいのか、どうしてそうしているのか分からない、何てことも少なくはないと思います。 この記事では、そのようなハマリどころについて Vinay さんなりの答えを提示し、簡潔かつ明快に解説してくれています。 今後 WebAPI を設計される方は、是非参考にしてみてください。 なお、誤訳がありましたら編集リクエストを頂けると幸いです。 まえがき アプリケーションの開発が進むにつれて、その WebAPI を公
「WebAPI 設計のベストプラクティス」に対する所感 - Qiita
「翻訳: WebAPI 設計のベストプラクティス」を読んで色々と思うところがあったので書きました。 上記の記事は訳文でありますので、正しくは「Best Practices for Designing a Pragmatic RESTful API」に対する所感と述べた方が良いのかもしれませんが、日本語で通して読めるよう Qiita に投稿された訳文に対する所感として書いています。 以下では「翻訳: WebAPI 設計のベストプラクティス」並びに「Best Practices for Designing a Pragmatic RESTful API」は「当該記事」と表現します。 観点 当該記事では「○○とした方がよい」との意見に対してそうすべき理由が明らかになっていないか、もしくは表現が曖昧な場合が目立っていると感じました。設計は実装のようにプログラム言語仕様が制約を与えられないため、意図
HerokuのAPIデザイン
Herokuが自ら実践しているAPIデザインガイドをGithubに公開した． “HTTP API Design Guide” このガイドは些細なデザイン上の議論を避けて，ビジネスロジックに集中すること目的としている．Heroku特有なものではなく，一般にも十分適用できる知見となっている． 最近は，モバイル向けにAPIをつくることも多いため，勉強もかねて抄訳した．なお内容は，HTTP+JSONのAPIについて基本的な知識があることが前提となっている． 適切なステータスコードを返す それぞれのレスポンスは適切なHTTPステータスコード返すこと．例えば，“成功"を示すステータスコードは以下に従う． 200: GETやDELETE，PATCHリクエストが成功し，同時に処理が完了した場合 201: POSTリクエストが成功し，同時に処理が完了した場合 202: POSTやDELETE，PATCHリク
バリデーションのベストプラクティス - ２４時間CakePHP
イントロダクション CakePHPの使い方は多種多様で、もちろん一つのやり方が正解ということはありません。 しかし、CakePHPはフレームワークであるわけで、想定された使い方以外ではその真価をなかなか発揮できません。 CakePHPにおけるモデルは、ビジネスロジックを置くレイヤとして想定されています。 そして、バリデーションを用いることによって保存のロジックを構築するということも想定されています。 これは、何故Cookbookで紹介されるコードが、ほとんどバリデーションとModel::save()の組み合わせであるかということかの答えにもなっています。 悪い例 あなたはModel::save()の代わりとして、以下のようなadd()メソッドをモデルに定義しているかもしれません: <?php class Post extends AppModel { var $validate = arr
CakePHPを使ったMVC設計のベストプラクティス - Sooey
CakePHPを使ったMVC設計のベストプラクティス 個人的にはCakePHPはあまり好きではないのですが、CakePHP開発メンバーによるMVCデザインの記事 (CakePHP のおいしい食べ方)で紹介されていたBest Practices in MVC Design with CakePHP (php|architect’s C7Y)はMVCフレームワーク利用者にとってとても有用な情報だったので、訳してみました(php|architectの方には翻訳許可を頂いています)。 この記事を読んでドメインモデルに興味を持った方は、エンタープライズ アプリケーションアーキテクチャパターン(PoEAA)やDomain-Driven Design: Tackling Complexity in the Heart of Softwareに手を出してみるのもいいかも。他に、InfoQにユーザー登録すれ
ネットワーク図の書き方 - Akio's Log
先月から出稼ぎで東京に来てます。毎年、プロジェクトの特性上、３〜４月に空きが出てしまうので、仕方のないことなんですが。 で、最近ネットワーク図を書く仕事をしているのですが、ちゃんとしたネットワーク図を仕事で書くのは初めてのことでしたので、「コツ」をつかむまでだいぶ時間がかかってしまいました。 その過程で、いろいろと参考にしたサイトをまとめてみます。 書籍 ネットワーク現場の教科書 改訂版 （マイコミムック） (MYCOMムック) 作者: IDG出版社/メーカー: 毎日コミュニケーションズ発売日: 2011/03/31メディア: ムック購入: 1人 クリック: 9回この商品を含むブログ (2件) を見るこれはネットワークの教科書 改訂版 （マイコミムック） (MYCOMムック)の実践編的な内容ですが、本当に役に立ちました。ネットワーク図を書く際には、物理構成図と論理構成図をきちんと分けて書か
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
