RESTful のウェブ API 設計で避けるべき 6 つのよくあるミス | Google Cloud 公式ブログ
※この投稿は米国時間 2022 年 12 月 1 日に、Google Cloud blog に投稿されたものの抄訳です。 オンラインで、組み立て式のテーブルを注文したとします。ところが、パッケージを開けてみると、組立説明書が入っていません。完成品がどんなものかはわかっていても、それぞれのパーツをどう組み立てればいいのか、まるでわかりません。設計が不十分な API を使うコンシューマ開発者も、同じような経験をしているといえます。適切に設計された API なら、容易に見つけ、検索してアクセスし、使用することができます。高品質の API は、コンシューマ開発者がアイデアをひらめき、新しいユースケースを作り上げる手助けになってさえくれます。 もちろん、API 設計を改善する方法はあります。たとえば、RESTful のプラクティスに従うなどです。しかし、お客様が知らず知らずのうちに、ちょっとした不便
今さら聞けない REST とリソース指向 - Mirai Translate TECH BLOG
概要 こんにちは。プラットフォーム開発部でリードエンジニアをしているchanceです。 私たちのチームでは現在、開発部内向けの API 設計ガイドラインを整備しようとしています。 API 設計において、REST は基本中の基本です。ガイドラインとしてまとめるからには適当なことは書けませんので、改めて REST の原則から確認しました。新しい技術を追いかけるのはもちろん重要ですが、こういった基本の技術をしっかりと理解することも同じように重要です。 この記事では、調べた内容のシェアとして、REST の誕生から原則、リソース指向アーキテクチャの概要や特性などを解説します。文字文字しくなってしまいましたが、ご容赦ください。 概要 REST の誕生 REST の原則 原則はいくつあるのか 書籍「RESTful Web Services」 ROA（リソース指向アーキテクチャ）について ROA（リソース
スプレッドシートとAWSでコストかからない業務システムを作る設計TIPS
はじめまして @shimma です。本業はD2C企業のCTOとして働く傍ら、業務支援として複数社、インフラを中心に直接手を動かして、社内で横展開できるような設計・コードベースをご提供しています。 枯れた技術で コード行数少なく 運用コストかからず 8-9割くらいのことを解決できる こちらが私の設計がポリシーです。 世の中9割はスプレッドシートで解決できる 私達の想像以上に、世の中の困りごとの大半はスプレッドシートやエクセルで解決ができます。エンジニアに依頼しなくても直接ロジック変更できるなど、組織リソースの有効化としてもメリットあります。 一方、複雑な数式やマクロにすべてを寄せ切り、ロジックを育てていくと、メンテナンスが困難を極めていきます。この記事を読んで頂いている技術者の方々であれば 複雑な箇所はコードによせて 変更しやすい所はスプレッドシート／Google App Script とい
API設計スキルを次のレベルに引き上げるベストプラクティス22選 - Qiita
本記事は、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つの重要な概念で構成されています。 リソース：データの一部（例：ユーザー） コレクション：リソー
LAMP 構成のシステムが抱えていた問題を Amazon API Gateway + AWS Lambda のサーバレス構成にして解消した話 - WILLGATE TECH BLOG
ウィルゲートのアーキテクト兼技術広報の岡田（@okashoi）です。 今からおよそ 1 年前に取り組んだ、社内システムをリニューアルによってサーバレス化した事例についての紹介と、1 年経過したところのふりかえりや所感を書きたいと思います。 システムリニューアルの背景 利用量の増加に対してスケールしにくい サーバリソースの利用効率が悪い エラーが発生した場合の原因究明が難しい リニューアルプロジェクト発足 目的は「スケーラビリティ向上」 「コスト削減」 「信頼性向上」 メンバー3 名でおよそ半年にわたるプロジェクト 目的へのアプローチ Amazon API Gateway + AWS Lambda によるサーバレスアーキテクチャの採用 Amazon Elasticsearch Service を用いたログの可視化と運用を考えたログ設計 プロジェクトでの取り組み 機能の洗い出し Go 言語 +
「The Twelve-Factor App」を15項目に見直した「Beyond the Twelve-Factor App」を読んだ - kakakakakku blog
2012年に Heroku のエンジニアによって提唱された「The Twelve-Factor App」は素晴らしく，アプリケーションをうまく開発し，うまく運用するための「ベストプラクティス」として知られている．2020年になった現在でもよく引用されていると思う．日本語訳もある． 12factor.net Beyond the Twelve-Factor App とは？ クラウド化が進むなど，提唱された2012年と比較すると技術的な変化もあり，今までの「The Twelve-Factor App」で宣言されていた観点以外にも必要な観点やベストプラクティスがあるのでは？という意見もある．そこで，2016年に Pivotal のエンジニアが「Beyond the Twelve-Factor App」を提唱した．The Twelve-Factor App にあった「12項目をアップデート」し，新
Anti-patterns of Web API’s
Web API’s are request-response message services that run on HTTP servers (e.g. IIS, Apache, Nginx). Web API’s started as informal client/server RPC-style interfaces in the 1990’s, then evolved to more structured SOAP-styled, XML-centric services (2000’s) and more recently settled onto RESTful services using JSON that have become the defacto standard for delivering enterprise information services o
Bonfire API #1 APIのリトライ処理
1. The document discusses RESTful APIs and gRPC, comparing their characteristics and use cases. 2. RESTful APIs typically use HTTP and JSON to access resources via URLs while gRPC uses protocol buffers and HTTP/2 for efficient streaming and RPC. 3. gRPC is better suited for microservices and mobile apps due to its ability to handle streaming and performance, while REST is more widely used due to i
RESTful API の設計のキホン
2016/10/12 社内勉強会で使ったスライドを社外向けに一部加筆訂正したもの
APIデザインにおける七つの大厄介 | POSTD
(編注：2016/7/29、頂いたフィードバックを元に記事を修正いたしました。) APIをデザインするということは、科学であり技術でもあります。多くの頭の良い人たちが失敗を重ねてきました。成功している人たちは、APIの主な目的を念頭においてデザインしているのです。その目的とは、「開発者たちをウンザリさせる」ということです。 親愛なる仲間たち、その崇高っぽい追求を称えるべく、「APIデザインにおける七つの大厄介」を共に数え上げようではありませんか（私がしたことを見てください）。 リスティクル（箇条書き形式の記事） を書くつもりはないのですが、少なくともタイトルは 教養ある宗教的文献が参照元 です。 まず、ルールを決めましょう。ここでは、成功し、きちんと機能しているAPIを取り上げます。ですから、「動かない」とか、「大量のセキュリティホールがある」といったことは厄介ごとに数えません。「致命的」
高い互換性と寿命の長いWebAPIをつくるには - トレタ開発者ブログ
Web APIの開発を担当しているswdyhです。 以前からWebサービスのサーバサイドの開発をしていたんですが、トレタに入るまでアプリのためのWeb APIの開発というのはしていませんでした。トレタに入って2年半くらいずっとアプリのためのAPIを開発していて、同じサーバサイドの開発でも、それまでとの開発とは違う点があり、悩ましくも面白く感じたのでまとめてみました。 サービスとアプリの話 トレタで提供しているサービスは、飲食店むけの予約管理サービスで、電話などで予約を受け付けたときに、iPadのアプリを操作して予約を入力してもらい、実際にお客さんが来店したときにはiPadを見て案内するというふうに使ってもらうものです。他にもいろんな機能やこだわりポイントがあるサービスなんですが、そのへんはWebサイトを見てみてください。 トレタのアプリはiPadのネイティブアプリで、ほぼ全てのデータをサー
5分で絶対に分かるAPI設計の考え方とポイント
API設計を学ぶべき背景と前提知識、外部APIと内部API、エンドポイント、レスポンスデータの設計やHTTPリクエストを送る際のポイントについて解説する。おまけでAPIドキュメント作成ツール4選も。 【0分】API設計を学ぶべき背景 APIの公開が増えている 最近、自社で保有するデータや、システム、アプリケーション、Webサービスの機能を「API（Application Programming Interface）」として公開する企業が、増えてきています。これに伴い、「API経済圏（APIエコノミー）」という新たなビジネスモデルが確立されつつあります（参考：5分で絶対に分かるAPIマネジメント、API経済圏）。 「ProgrammableWeb」というAPIに関するニュースサイトや、さまざまな企業が提供するAPIのリンクがまとまったサイトもあり、APIの普及はものすごいスピードで進んでいる
Heroku HTTP API Design Guide
Tokyo Salesforce Developer Group 2017 新年会 https://www.meetup.com/ja-JP/Tokyo-Salesforce-Developer-Group/events/236348361/ で発表したLTの資料です PPL2015 ポスター発表の内容です。かなり適当なスライドなのでここで補足します。 【概要】 残念なぐらい使いにくい画面のソフトウェア（あるいはサービス）というのがたくさんあります。で、その原因のひとつには「ただHTMLをゴリゴリ書くだけでは、人間がどう考えてどう操作するかはどこにも書かれていない」ということにあると考えました。だから、依存型付き関数型言語であるAgdaを使ってその部分を形式的に記述すれば、残念な画面が減ってもっとみんな幸せになるだろう、と考えています。Agdaを使うとうまくいけそうだ、という予想の根拠はい
アプリエンジニアから見てAPI設計において気をつけてもらえるとうれしいこと - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? by @mixiappwchr アプリ向けのAPIの開発時に気をつけてもらえるとうれしい＆メンテナンスや実装コストが下がる点をつらつら書きます。 データ構造について データを返すとき、一定のルールを守って返す。例えば当然ですが同じデータ構造はもちろん、似たような構造もルールを作ってproperty名などそろえておく。relationやlistで返すときもどのデータ構造なのかがpropertyで明確にわかるようなっているようにする listを返す場合の形式やpagingが必要な場合の形式はそろえる。配列のデータがない場合も考慮しておく。例
Web APIを作るときに考えること。 - パルカワ2
この記事はPepabo Advent Calendar 2014の11日目の記事です。 前日は、tnmtさんのVagrantのshell provisionerでApacheのビルド済tarボールをOSバージョン毎に作る術でした。 はじめに 今回は、Web APIを作るときに考えることをまとめました。 本当は、社内向けに資料を作っていて、社内の勉強会とかで話せればいいか〜って考えていたんですが、アドベントカレンダーのネタが本当になくて困っていたのでこれを使います。 対象者 APIを作る時、と書いてますが、クライアント側の人にとっても知っておく必要があることなので、サーバ側の人・クライアント側の人両方が対象者です。 APIを作るときに考えること 「APIを作るとき」と言っても、色んな状況があります。 まずはそれを絞ります。 APIの種類 プライベートAPI アプリのAPIなど使う人が限定され
権限管理を実装するときの地味な話 - ✘╹◡╹✘
「あるユーザがXをYできるかどうか」というメソッドを定義したいとき、Userに実装するよりも、Xに実装した方がうまくいくことが多かった。例えば「ユーザが投稿を編集できるか」という、ブログの共同編集のような機能で使うやつで考える。つまり、User#can_edit?(entry) みたいなやつにするか Entry#editable_by?(user) みたいなやつにするかという話になる。 後者の方でうまくいった理由は、Webアプリだとログイン中のユーザが存在しない場合というのがあるが、後者ではuserがnilの場合でも対応できたというのと、Userクラスが長大にならなかったという点 (Abilityクラスとかを全ての場所で統一して使えている場合はそれで良いので各自適当にやっていってほしい)。あとメソッドの命名規則の問題があって、名詞形 (例:User#name) か、xxx?で終わるメソッド
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
セキュアなWeb APIの作り方 / Secure Web API