18

サイト自体が実際にAPIを使用するように、サイトの開発中にAPIを開発することは良い習慣ですか？または、これを選択した場合、パフォーマンスが低下しますか？

たとえば、FacebookやDiggなどの成熟したサイトが独自のAPIを使用してCRUD（作成、読み取り、更新、削除）を行っているかどうか、または独自のバックエンドを持っているかどうかを誰かが知っていますか？ありがとう

4

4 に答える 4

14

Facebookなどが独自のAPIを使用しているとは思えません。サイト自体に独自のAPIを使用しない理由はいくつかあります。

  1. 追加の要求や（逆）シリアル化を行う代わりに、データベースを直接使用することで、データアクセスのパフォーマンスを向上させることができます。
  2. memcachedなどを使用して効率的なキャッシュを実装する方がおそらく簡単です
  3. 重要なのは、サイトを拡張するときにパブリックAPIに準拠する必要がないことです（パブリックAPIを頻繁に変更する必要はありません。これは、すべての人を困らせるだけです）。
于 2010-08-28T11:30:21.247 に答える
2

ブラウザ自体がなくても使用できるアプリケーションへの低レベルのインターフェイスを用意し、サイトがそのインターフェイスを使用して処理を実行することをお勧めします。

そのインターフェースはAPI自体である必要はなく、APIよりもレベルが低く、APIと本番Webサイトの両方で使用されるレイヤーである可能性があります。

APIがWebサイトを複製するだけの場合は、一般的に悪い考えです。

つまり、以下は悪いです

# hypothetical example of bad duplication

def website_update_blog_post(request):
    user = request.username()
    ensure_logged_in(user)
    post = Posts.objects.upsert(request.post_title, request.post_body)
    trigger_notifications(post)

.....

def api_update_blog_post(user, password, title, body):
    verify_login(user, password)
    post = Posts.objects.upsert(title, body)
    trigger_notifications(post)
于 2010-08-28T11:49:58.680 に答える
0

いいえ、独自のCRUDツールやORMSを作成しないでください。API /フレームワーク/ユーティリティを構築するためのすべてのハードワークがすでに行われている、すぐに使えるフレームワークが十分にあります。それらを使用することで、生産性のメリットを享受できます。彼らはまた、パフォーマンスへの影響も考慮しているでしょう。唯一のペナルティは、それぞれの小さな学習曲線です。

とはいえ、アプリが大きくなり、古くなっても、これらのAPIを使用して均一性（および保守性）を確保するための標準的な方法/プラクティスを定義することはできます。

また、変更から自分自身をさらに保護したい（または賭けをヘッジしたい）場合は、インターフェースと依存性逆転（DIやサービスロケーターパターンなど）を使用して、サードパーティのコンポーネントとフレームワークを抽象化できます。

于 2010-08-28T11:39:50.043 に答える
0

たとえばMVCフレームワークをバックエンドとして使用している場合は、そのようなCRUD APIをすでに取得しています。または、たとえばDBなど、ある領域に向けられたORBフレームワークのようなものを使用し、それらのAPIを使用してアプリケーション、またそれは何でもありえます。

ただし、特に最初は、生のSQLを使用することはお勧めしません。それで、あなたの好みとウェブプロジェクトの目標をサーバーサイドの言語で教えてください。コミュニティはいくつかの新しいアイデアであなたにアドバイスするかもしれません。

于 2010-08-28T11:29:34.493 に答える