apiに関するhagyroomのブックマーク (6)
-
本記事は、Mohammad Faisal氏による﹁22 Best Practices to Take Your API Design Skills to the Next Level﹂︵2021年4月15日公開︶の和訳を、著者の許可を得て掲載しているものです。 REST API設計のための実践的アドバイス Photo by Andrea Piacquadio from Pexels はじめに すべてが分かりにくく、ひどいAPIに不満を感じたことはありませんか？私はそうです。 マイクロサービスの世界では、バックエンドAPIの一貫した設計が不可欠です。 今日は、知っておくべきベストプラクティスについて、簡潔に説明します。さあ始めましょう！ 用語 API設計は、リソース指向設計というものに従います。3つの重要な概念で構成されています。 リソース‥データの一部︵例‥ユーザー︶ コレクション‥リソー
-
これは Enchant の開発者である Vinay Sahni さんが書いた記事﹁Best Practices for Designing a Pragmatic RESTful API﹂1を、ご本人の許可を得て翻訳したものです。 RESTful な WebAPI を設計しようとすると、細かなところで長考したり議論したりすると思います。また、他の API に倣ってやってはみたものの、本当にそれでいいのか、どうしてそうしているのか分からない、何てことも少なくはないと思います。 この記事では、そのようなハマリどころについて Vinay さんなりの答えを提示し、簡潔かつ明快に解説してくれています。 今後 WebAPI を設計される方は、是非参考にしてみてください。 なお、誤訳がありましたら編集リクエストを頂けると幸いです。 まえがき アプリケーションの開発が進むにつれて、その WebAPI を公
-
HTTPステータスコードを返すというのはとても単純なことです。ページがレンダリングできた？よし、それなら 200 を返しましょう。ページが存在しない？それなら 404 です。他のページにユーザをリダイレクトしたい？ 302 、あるいは 301 かもしれません。 I like to imagine that HTTP status codes are like CB 10 codes. "Breakerbreaker, this is White Chocolate Thunder. We'vegot a 200 OK here." — Aaron Patterson (@tenderlove) 2015, 10月7訳‥HTTPのステータスコードのことは、市民ラジオの10コードみたいなものだと考えるのが好きです。﹁ブレーカー、ブレーカー、こちらホワイト・チョコレート・サンダー。200
-
小文字のみを使用する。 単語をつなげる必要がある場合はダッシュを利用する。 単数形よりも複数形をつかう。なお、実装がRailsの場合でテーブルの複数形が誤っている場合には、URLは正しい複数形としてRails側を修正する。︵APIに実装を反映させるべきではない。︶ スペルミスをしない。 URLの階層は浅く保ち、複雑さはクエリパラメーターに押しこむ。 クエリパラメータ名は配列で複数渡すものについては複数形、一つだけ渡すものについては単数形とする。 ページングにはper_page、pageというパラメータ名を使用する。 と書いてきたが、ただし、RESTには必ずしもこだわらず、あくまで利用側の利便性を重要視した設計とする。1つの作業を完結するために複数回のアクセスを必要とするようなAPIの設計はChatty APIと呼ばれる。これはネットワークのトラフィックを増加させ、クライアントの処理の手間
-
DevTools、使ってますか？ もはやChromeじゃないと開発できないくらいに飼い慣らされています。 ブレークポイントやconsole.logなど基本的な使い方から、TimelineとAuditsを使ってのパフォーマンス計測などなど、DevToolsのポテンシャルは計り知れません。 個人的にはConsole APIが好きなんですが、今回はConsoleパネルで使える Command Line API の使い方についてまとめてみました。 $_ $_には最後に評価した式の結果が保存されています。 Console上で計算を行なった場合や、$セレクタなどでDOMを検索した結果など、最後の結果が常に保存されます。 $0 〜 $4 $0から$4にはElementsパネルで選択した要素が5つ保存されています。$0が最後に選択した要素で数字が増えるごとに過去に選択した要素になります。 $0は特に使いや
-
-
1
API設計スキルを次のレベルに引き上げるベストプラクティス22選 - Qiita
翻訳: WebAPI 設計のベストプラクティス - Qiita
HTTPステータスコードを適切に選ぶためのフローチャート : 難しく考えるのをやめよう | POSTD
Web API設計指針を考えた｜デロイト トーマツ ウェブサービス株式会社（DWS）公式ブログ
覚えておきたいDevToolsのコマンドラインAPIまとめ - Qiita
休日情報 Web サービス
