APIを設計する前に読みたいガイドラインまとめ | NTT Communications Developer Portal
APIというのは主に外部の開発者が見ることになります。そしてその設計思想が彼らの思いとマッチしていないと使うのを嫌がられることになります。逆にエレガントで統一性のあるAPIは開発者を刺激し、使おうという姿勢に変えてくれます。 そこで今回は多くのAPIを提供している各社がリリースしたAPIガイドラインを紹介します。 interagent/http-api-design: HTTP API design guide extracted from work on the Heroku Platform API Herokuが実践しているAPIデザインガイドになります。ステータスコード、リソース、タイムゾーン、パスの付け方、バージョニングなど数多くの項目に渡って記述されています。 API開発指針 | EC-CUBE3 国産Eコマースシステム、EC-CUBE3におけるAPI開
RESTful APIのURI設計(エンドポイント設計) - Qiita
RESTful APIのリソース設計で述べた通り、何をリソースとするかを決めたらそのリソースを識別するURIを検討する必要がある。 エンドポイントとは何か エンドポイントとはAPIにアクセスするためのURIのこと。例えば、QiitaのAPIで自分の情報を取得する時のエンドポイントは以下となる。 http://qiita.com/api/v2/users/nagaokakenichi 似たような言葉に「エントリポイント」というものがある。エントリポイントとはプログラムやサブルーチンの実行を開始する場所のこと。 Qiita視点で考えると、 http://qiita.com/api/v2/users/nagaokakenichi を参照されることでプログラムが開始されるので、Qiitaからすると上記URIはエントリポイントとなる。 つまり、エンドポイントはAPIにアクセスする側からの、エントリポ
grpc-gatewayの開発に学ぶ、ソフトウェアの設計手法〜Yuguiが定めた、2つの基本設計方針 - エンジニアHub｜若手Webエンジニアのキャリアを考える！
grpc-gatewayの開発に学ぶ、ソフトウェアの設計手法～Yuguiが定めた、2つの基本設計方針 良いソフトウェアとはどのような方針のもとに設計されているのでしょうか。広く使われているOSSであるgrpc-gatewayの開発過程を作者のYuguiさんが振り返り、その設計手法を解説してもらいました。 こんにちは。 Yuguiと言います。 本記事では読者がより良いソフトウェア設計を行うための参考として、筆者が経験してきた設計上の決定をご紹介します。 筆者はこれまでRuby 1.9のリリースマネジメントを担当したり、Google Mapsの日本向け地理データ処理やgrpc-gatewayの開発などをしてきました。そしてこれらを通じて、広く長く使われて拡張されていくソフトウェアを設計するための方針決定に携わったり、方針に関わる良い議論を目にしたりする機会に恵まれてきました。中でも本記事では、
REST入門 基礎知識 - Qiita
REST入門 基礎知識 はじめに RESTサービスを開発するにあたって勉強したことをまとめました。RESTとはなんぞやというところについて書いていきます。実際の開発方法等については当記事では触れません。 RESTとは REST(REpresentational State Transfer)はWebサービスの設計モデルです。RESTなWebサービスは、そのサービスのURIにHTTPメソッドでアクセスすることでデータの送受信を行います。 例としてQiitaのREST APIを利用してみます。下記のURLにアクセスしてみてください。(ChromeかFirefoxでないと*.jsonファイルのダウンロードになる場合があります) https://qiita.com/api/v2/users/TakahiRoyte {}でくくられている文字が表示されたかと思います。これは JSON(JavaScri
API設計に関する10のワーストプラクティス | gihyo.jp
ソーシャル機能の実装など外部サービスのAPIを使ったアプリケーションが増える中、「使いづらい設計のAPI」は、開発者にとっては頭の痛い問題ではないでしょうか？ Programable Web注1上に投稿されたAPIのワーストプラクティスに関する記事が国内外の開発者の目に止まり話題になっています。この記事によると悪いAPIに見られるプラクティスは次のようなものだそうです。 貧弱なエラーハンドリング HTTPのルールを無視したREST API 裏に潜んだ生のデータモデルの露出 セキュリティの複雑さ ドキュメント化されていない予期せぬリリース 貧弱なデベロッパエクスペリエンス MVC（Model-View-Controller）フレームワークが良いAPIにしてくれるという思い込み 開発すれば使ってもらえるとみなすこと 不十分なサポート 貧弱なドキュメント 自分自身のサービスがAPIを公開する場
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
