綺麗なAPIを設計するには気をつけたい5つのポイント | NTT Communications Developer Portal
綺麗なAPIとは開発者にとって理解しやすく、使いやすいAPIです。さらに提供側にとってはメンテナンスしやすく、拡張性も担保されたものになります。そうしたAPIを設計するのは容易ではありませんが、幾つかのルールを設けておくことでも十分に綺麗に設計できるようになるでしょう。 1. モデル型かアクション型か URLを設計する際にRESTfulに作るのがデファクトになっていますが、その中でもURLの作り方をモデル（ユーザ、商品など）にするか、アクション型（購入する、出席するなど）にするかで分かれます。どちらを採用するにしても明確な基準が必要です。両方を満遍なく取り入れると、非常に分かりづらいものになります。 一般的には GET /users/1 でユーザデータに対する操作であるといった形にします。つまりモデル型です。 となると POST /purchase で購入するというアクションを定義するより
InfoQ: RESTfulなアプリケーションを記述する
しかしながら、上述のRoy Fieldingの言葉を言い換えると、このようなアプローチはRESTの基本的な原則の一部と相反します。たとえ私たちがこの異議を無視するとしても、 HTTP上に分散型アプリケーションをRESTfullに構築しようとしている人たちには、根本的な問題が残ります。契約を形式的に定義することなくサーバーからの取得はどうするのでしょうか？契約なしでクライアントとサーバーが正しく実装しているということをどのように確かめるのか、それぞれの設計仕様書だけでなく、その他、適切なビジネス/技術ポリシーはどうするのでしょうか？ アプリケーションプロトコルとしてHTTPを使用し、RESTfullな構築をしている分散型アプリケーションには、同じような性質と種類の契約があります。私たちは、何を探し、どこを探すかを知る必要があります。同じ方向にしたがい、私たちが記述言語に向かうならば、それはW
【図解】RESTful WebサービスにおけるHTTPステータスコード : アジャイル株式会社
RESTful WebサービスではHTTPステータスコード=処理結果 弊社 アイコン認証Webサービス は、REST方式のWebサービスとして実装されています。 REST方式でない通常のWebアプリケーションでは、通常HTTPステータスコードとしては200(OK)しか返されません。 エラー等の状態を表す場合でもHTTPステータスは200(OK)が返され、画面に表示される内容にエラーを表すメッセージ等を含ませる事によって状態を表現します。 RESTfulなWebサービスを実現する場合には、処理結果はHTTPステータスコードで表現するべきとされています。 理由としては、以下のものがあげられます。 適切なHTTPステータスコードを返さない ( 全部 200 (OK) とかの ) 場合、エンティティの中身を解析しなければ、処理結果が判別できない。 Web標準に従う事で、HTTPステータスコードから
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
