2

既存のデータベース 用の新しいAPIの開発を支援しています。

Python 2.7.3、Django 1.5、およびdjango-rest-framework2.2.4をPostgreSQL9.1で使用しています

APIの優れたドキュメントが必要/必要ですが、私は略語であり、ドキュメントの作成/保守が嫌いです（私の多くの欠陥の1つ）。

APIの利用者が新しい「POS」（POS）の場所を追加できるようにする必要があります。Postgresデータベースには、posからpos_location_typeへの外部キーがあります。したがって、ここに簡略化されたテーブル構造があります。

pos_location_type(
  id serial,
  description text not null
);

pos(
   id serial,
   pos_name text not null,
   pos_location_type_id int not null references pos_location_type(id)
);

したがって、新しいposをPOSTできるようにするには、「pos_name」に有効なpos_location_typeを指定する必要があります。だから、私は週末中ずっとこのことについて読んでいました。そこにはたくさんの議論があります。

APIコンシューマーは、pos_location_typeが何であるかをどのように知るのでしょうか。または、ここで渡す値は何ですか？

pos_locationsの有効なリストをどこで入手するかを彼らに伝える必要があるようです。何かのようなもの：

GET /pos_location/

簡単に言うと、pos_location_typeの説明の例は次のようになります:('school'、'park'、'office'）。

私はDjangoRESTFrameworkの「参照可能性」が本当に好きですが、この種のことには対応していないようです。実際、今日の初めにトム・クリスティーとIRCで非常に素晴らしいチャットをしましたが、彼は実際にはそうではありませんでした。ここで何をすべきかについての答えがあります（または、質問を明確にしたことがないかもしれません）。

私はSwaggerを見てきましたが、これは非常にクールで興味深いプロジェクトですが、ここでデモの「ペット」リソースを見てください。それは私がする必要があることとかなり似ていることに注意してください。新しいペットを追加するには、カテゴリを渡す必要があります。カテゴリは、クラスCategory（id：long、name：string）として定義されています。消費者は、ここで何を渡すかをどのように知っていると思いますか？有効なIDは何ですか？または名前？

Djangoレストフレームワークでは、OPTION呼び出しで返されるものを定義/オーバーライドできます。ここで自分の小さな「システム」を考え出し、次のような情報を返すことができると思います。

 pos-location-url: '/pos_location/'

一般的な形式では、次のようになります。{resource} -url：'/ path / to / resource_list'

それはドキュメンテーション側にとっては一種の仕事になるでしょうが、それがプログラム的に本当に素晴らしい解決策であるかどうかはわかりません。リソースの場所を変更するとどうなりますか。つまり、私の消費者はプログラムで作成する必要があり、OPTIONSはすべての関係を理解するためのリソースを要求します。悪いことではないかもしれませんが、少し変な感じがします。

では、人々はこの種のことをどのように処理するのでしょうか。

最後の注意：ここで「リーク」アブストアクションが本当に必要ではなく、データベースがAPIレイヤーを介してピークに達するという事実がわかりますが、この既存のデータベースとそれ以外の挿入には、foreign_key制約があります。有効なpos_location_type_idがエラーを発生させています。

また、私はURIとIDの議論を開くつもりはありません。ユーザーがpos_location_type_idint値を使用する必要があるか、URIを使用する必要があるかは、この説明では重要ではありません。どちらの場合でも、彼らは私に何を送るべきかわからない。

4

1 に答える 1

0

私は過去にこの種のものを扱ってきました。この問題に取り組むには2つの方法があると思います。最初にすでに述べたように、APIのユーザーがのIDのような値をエンドポイントで認識できるようにしますpos_location_type。多くのAPIはこれを行います。これは、APIから開発する人がドキュメントを読む必要があり、pos_location_type値をどこから取得するかを知っているためです。エンドユーザーは、おそらくテキスト値のドロップダウンリストを表示するインターフェイスを備えているため、これについて心配する必要はありません。

一方、私がこれを行った方法も、RESTfulのようなものではありません。ニューヨークに場所があり、POSTは次のようになっているとします。

POST /pos/new_york/

/ pos /（location_name）/を処理するには、テキストを正規化してから、データベースで値または類似性を検索します。場所が存在しない場合は、新しい場所を作成します。ユーザーが新しい場所を追加できる場合、そうでない場合、ユーザーはどの固定場所が存在するかを知る必要があります。これもまた、私たちが最初に直面する状況です。

そうすれば、リクエストデータで回避できるためpos_location_type、プログラムで有効なIDにマッピングできます。

于 2013-03-18T18:05:33.577 に答える