web-dev-qa-db-ja.com

JSON APIまたはプレーンJSON

JSON API仕様 を使用するか、またはiOSやAndroidを中心とするモバイルアプリで使用されるAPIを開発するためにプレーンJSONを使用するかについては、社内で議論があります。

JSON APIの引数の1つは、すべてが事前に定義されているため、新しい開発者がAPIの作業を開始した場合、必要なものをすばやく見つけることができるということです。もう1つは、ほとんどの関係を応答にバンドルできるため、サーバーの負荷を軽減できることです。

JSON APIに対する反対意見の1つは、これまで存在しなかった問題を引き起こすことです。プレーンJSONを使用する場合、同じタイプのリレーションシップまたはオブジェクトを保持する属性があります。たとえば、著者と発行者に関する情報を保持する小説をどこに置くかは、プレーンJSONは次のようになります。

{
    author: { 
                name: "John",
                lastname: "Appleseed",
                id: 1
            },
    title: "Some great novel",
    publisher: {
                   name: "Something"     
               }
}

そしてAndroid私はJSONをシリアル化するクラスを作成することができます。クラスはそのようなものでしょう

class Novel {
    String title;
    Author author;
    Publisher publisher;
}

class Author {
    String name;
    String lastname;
    int id;
}

class Publisher {
    String name;
}

その後、Retrofitは応答を解析し、Novel POJOを返します。

Swiftでは、SwiftyJSONを使用して同様の構造体またはクラスを作成できますが、唯一の違いは、クラスの値を設定するために追加のボイラープレートコードを記述する必要があることです。これは簡単なアプローチのようです。

ただし、JSON API実装を使用すると、はるかに複雑になり、読みにくくなります。

ほとんどの関係をバンドルして応答で返すことができるため、サーバーの負荷を軽減するという引数については、上記の例のようにプレーンなJSONで実現できます。

JavaまたはSwiftなどの静的に型付けされた言語でJSON APIを使用するのが良い選択であるかどうかについて、いくつかの洞察を使用できます

javaandroidiosjsonswift-language
6
gkaimakas

JSONには興味がありません。JSONから作成されたオブジェクトに興味があります。例のように、プレーンなJSONをオブジェクトに変換するのは簡単です。新しい開発者にとってそれはどのくらい難しいですか？主に彼らは作成されたオブジェクトに興味を持っています。彼らは、JSONをオブジェクトに変換するコードを見ることができます。

私はJSON API仕様を見ましたが、マゾヒスト以外には誰にも勧めません。

5
gnasher729

JSON APIは素晴らしいですが、複雑な仕様です。その実装も簡単ではありません。特に、適切なライブラリを実装していない場合はそうです。

それは主に「私たちのユースケースにとってそれだけの価値があるのか​​」という質問です。

私の意見では、大規模なAPIやパブリックAPIが安定していて拡張可能である必要があり、何年も開発される場合は価値があります。 JSON APIは、APIの妥当な標準を提供するため（独自のAPIを作成する必要はありません）、多くの高度なケースをカバーしています（今は考えていませんが、後で問題が発生します）、既存の実装があります。多くの言語とプラットフォームで公開され、明確に定義された仕様、既存のサポート、ユーザーベースなどがあります。

1つのクライアントと1つのサーバーの間のプライベートAPIであり、1年程度で完全に手直しされる可能性がある場合、小規模なチームが作業する価値はありません。

もちろん、これらのかなり極端なケースの間のどこかにある多くのプロジェクトがあり、決定は容易ではないかもしれません。

4
qbd

現在、SOAP APIと対応するWSDLを扱っています。JSONAPI仕様を調べたところ、REST JSONサーバー。

WSDLと同様に、JSON APIは世界で最も読みやすいとは言えません（ただし、WSDLよりも読みやすいです）が、必要なコードを作成するツールによって解析されることを意図しています。

JSONをSwift構造体に変換するには、大量のボイラープレートコードが必要です。確かに、コードは読みやすく、簡単に作成できますが、非常に面倒で時間がかかります。自動ツールで実行できる時間の無駄です。仕事。

とはいえ、SOAPとWSDLは絶滅しつつあり、自動化ツールが作成するコードを処理する必要がある理由の大部分は...生成されたコード自体は通常読みにくいですが、手動で更新するのは面倒です。

もちろん、自動生成されたコードの要点は、更新するためにhaveを実行しないことですが、手つかずのベースの真ん中にその大量のガベージコードを置くことは困難です。

時には美学が効率よりも重要です。

1
Daniel T.

新しいコンテンツと機能をクライアントに変更せずに動的に追加できるようにしますか？Json APIを使用する場合（そして実際にそれを活用する場合）、まさにそれを達成できます。

bookリソースのv1が次のようになっているとしましょう

links: { 
         self: "/books/1"
          next: "/books/2"
}
author: { 
            links: {
                 self: "/authors/1"
            }
            name: "John",
            lastname: "Appleseed",
            id: 1
        },
title: "Some great novel",
publisher: {
               name: "Something"     
           }

次に、購入する機能を追加することにします。

links: { 
         self: "/books/1"
          next: "/books/2"
          purchase: "/books/1/purchase"
}

すべての可能なアクション（links）のみを表示するようにクライアントを構築している場合は、購入機能を追加しただけです。すべてのクライアント。サーバーから返されるものを更新するだけです。

ステフェン・ティルコフの講演を観ることを強くお勧めします： REST：それがあなたの考えていることを意味しているとは思わない 。

0
RubberDuck