タグ付けされた質問 「json」

多くの開発者がXMLとJSONに精通していると確信しており、彼らは両方を使用しています。したがって、彼らが何であり、彼らの目的が何であるかを簡単に説明しても意味がありません。 それらの概念をマップしようとすると、言うことができます（私が間違っている場合は修正してください）： XMLタグはJSONと同等です {} XML属性はJSONプロパティと同等です XMLタグコレクションはJSONと同等です [] 私が考えることができる唯一のものは、JSONには存在しませんが、XML Namespacesです。 問題は、このマッピングを考慮し、JSONがこのマッピングで非常に軽いことを考えると、XMLなしで将来（または少なくとも理論的には世界を考える）の世界を見ることができますが、JSONでXMLのすべてを実行できますか？XMLが使用されるすべての場所でJSONを使用できますか？ PS：この質問を見たことがあることに注意してください。これは私がここで尋ねているものとはまったく異なるものです。したがって、重複を言及しないでください。

78 xml  json 

アプリケーションの構成には常にJSONファイルを使用しています。私は多くのJavaをコーディングしたときからそれらを使い始めましたが、現在は主にサーバーサイドとデータサイエンスのPython開発に取り組んでおり、JSONがこれ以上正しい方法であるかどうかはわかりません。 Celeryが実際のPythonファイルを構成に使用するのを見てきました。当初、私はそれについて懐疑的でした。しかし、構成に単純なPythonデータ構造を使用するという考えは、私に成長し始めています。いくつかの長所： データ構造は、通常コーディングしているものと同じです。そのため、心のフレームを変更する必要はありません。 私のIDE（PyCharm）は、構成とコードの関係を理解し​​ています。Ctrl+ Bを使用すると、構成とコードを簡単に切り替えることができます。 IMOの不要な厳密なJSONを使用する必要はありません。二重引用符、末尾のコンマ、コメントはありません。 作業中のアプリケーションでテスト構成を作成し、変換やJSON解析を行わずに簡単に構成ファイルに移植できます。 本当に必要な場合は、構成ファイルで非常に簡単なスクリプトを実行することができます。（これは非常に制限されるべきですが。） だから、私の質問は次のとおりです。切り替えた場合、どのように自分の足を撃ちますか？ 熟練していないエンドユーザーが構成ファイルを使用することはありません。構成ファイルへの変更はすべてGitに現在コミットされており、継続的な展開の一部としてサーバーにロールアウトされています。緊急事態があるか、開発中でない限り、手動で構成を変更することはありません。 （私はYAMLを検討しましたが、それについて何かが私をいらいらさせます。それで、今のところ、それはアメリカのテーブルから外れています。）

72 python  json  configuration  configuration-management  python-3.x 

現在、Slim Frameworkを使用してソーシャルネットワーク用のAPIをコーディングしています。私の質問は、json構造に返す行がない場合のベストプラクティスは何ですか？ この呼び出し/ v1 / get / moviesがテーブルmovie namesから2行を返すとしましょう： [ {"name": "Ghostbusters"}, {"name": "Indiana Jones"} ] しかし、それから/ v1 / get / booksを呼び出すと、そのテーブルには行がありません。空の構造を返すだけですか？ [ ] ...または、メッセージとエラーコードの方が良いでしょうか？ [ "errors": { "message": "no matches found", "code": 134 } ] どちらが良い方法ですか？（APIはiOSおよびAndroidアプリで使用されます）ありがとう！

50 programming-practices  rest  api-design  json 

このようなリソースがあるとします book: type: object properties: author: {type: string} isbn: {type: string} title: {type: string} books: type: array items: book したがって、誰かがGET本のリソースを作成すると、次のように返されます [{"author": "Dan Brown", "isbn": "123456", "title": "Digital Fortress"}, {"author": "JK Rowling", "isbn": "234567", "title": "Harry Potter and the Chamber of Secrets"}] 職場の誰かから、推奨されるRESTプラクティスは、常にJSONオブジェクトとして応答を返すことであると聞きました。つまり、スキーマbooksは次のようになります。 books: type: object properties: list: type: array items: …

40 rest  json 

私のアプリケーションでは、一部のユーザーは姓を教えてくれますが、他のユーザーは教えません。REST APIレスポンスでは、どのボディが優先されます： 「ヌル」値の場合： {"firstName": "Bob", "lastName": null} または、不足しているキー： {"firstName": "Bob"}

40 rest  api-design  json 

JSON APIに関しては、応答をフラット化し、ネストされたJSONオブジェクトを避けるのが良いでしょうか？ 例として、IMDbに似ているがビデオゲーム用のAPIがあるとします。いくつかのエンティティ、Game、Platform、ESRBRating、GamesとPlatformsをマップするGamePlatformMapがあります。 ID 1のゲームを取得する/ game / 1をリクエストすると、プラットフォームとesrbRatingがネストされたゲームオブジェクトを返します。 { "id": 1, "title": "Game A", "publisher": "Publisher ABC", "developer": "Developer DEF", "releaseDate": "2015-01-01", "platforms": [ {"id":1,"name":"Xbox"}, {"id":2,"name":"Playstation"} ], "esrbRating": { "id": 1, "code": "E", "name": "Everyone" } } JPA / Hibernateのようなものを使用している場合、FETCH.EAGERに設定されていれば自動的にこれを行うことがあります。 もう1つのオプションは、単にAPIを追加して、エンドポイントを追加することです。 その場合、/ game / 1が要求されると、ゲームオブジェクトのみが返されます。 { "id": 1, "title": "Game …

37 design  rest  api-design  json 

JWTのクレーム/ペイロードをbase64デコード後に公開する理由を理解できません。 どうして？ シークレットで暗号化する方がはるかに便利だと思われます。 誰かがこのデータを公開することがなぜ役に立つのか、どのような状況で役立つのかを説明できますか？

30 security  json  authentication  jwt 

私は、標準のSQLリレーショナルデータベースまたはJSONオブジェクトを使用して、イベントまたはアクティビティに関するデータを保存するかどうかを決定しようとしているプロジェクトに取り組んでいます。 プロジェクトは複数のイベントタイプのデータを保存するため、この質問に対して1つのイベントタイプのみを説明することにしました。 ライブ音楽イベント（この質問の最後にあるJSONスキーマを使用して詳細に説明します）は、イベントが行われる場所、イベントの日時、イベントのコストなどのデータを格納するオブジェクトです。ライブ音楽イベントオブジェクトには、1対1（イベント->名前、イベント->説明）と1対多（イベント->会場、イベント->日付、イベント->チケットタイプの両方があります。 ）関係。さらに、イベントオブジェクトには、パフォーマーオブジェクトにリンクする1つ以上のパフォーマーIDを含めることができます。演奏者オブジェクトは、ライブ音楽イベントで演奏しているミュージシャンのデータを保存します。 データは、単純（「x名前のイベントを検索」）と複雑（「現在の音楽ジャンルから半径「z」以内の「x」音楽ジャンルと「y」コストのイベントを検索」」の両方を使用してユーザーに照会されます場所」）クエリ。データは、ユーザーがWebフォームを使用して送信します。 おそらく定義済みのJSONスキーマからわかるように、私はもともとJSONオブジェクトを使用してこのデータを保存するつもりでしたが、私のデータは純粋にリレーショナルであるため、古いメソッドに固執する必要があると言う人がいます。 私のニーズを考えれば、それぞれのアプローチの長所と短所についてのご意見をいただければ幸いです。明確なものが必要な場合は、お気軽にお問い合わせください。 { "event": { "eventID":{ "type":"string" }, "eventType":{ "type":"array", "eventTypeItem":{ "type":"string" } }, "eventName":{ "type":"string" }, "eventDescription":{ "type":"string" }, "eventVenueList":{ "type":"array", "eventVenueListID":{ "type":"integer" } }, "eventURL":{ "type":"string" }, "eventTwitter":{ "type":"string" }, "eventFB":{ "type":"string" }, "eventInstagram":{ "type":"string" }, "eventEmail":{ "type":"string", "format":"email" }, "eventContactPerson":{ "type":"string" }, …

28 design  sql  json 

現在のプロジェクトでは、JSONのみをサポートするものとして文書化されている、新しく作成されたRESTful APIの使用を伴うサービスの実装を担当しています。 クライアントは、一貫して「application / json」のacceptヘッダーと「application / json」のcontent-typeで要求を行います。ただし、一部のエンドポイントは、HTMLのコンテンツタイプ、さらにはHTML本文で応答を送信します。私にとってこれは明らかに間違ったアプローチであり、正当化することはできません。 プロジェクト全体を通して、この同じプラクティスが2つの異なるベンダーと2つの異なるサービスに適用されています。サービスを変更する必要がある理由を正当化する必要があることに気づきました。ベンダーは、クライアントはこれに対処する必要があると述べており、デフォルトの「箱から出して」これに対処しないため、選択したRESTライブラリでさえ疑問視されています（RestEasy）。 これはフラストレーションの大きなポイントでした。私の主張を裏付ける多くの参考文献を見つけることができません。これは、それが非常に明白であるので、ポイントが議論の余地があるからだと思います。 問題は、何かが足りないということですか？私はこれについて熱心ですか？このシナリオでcontent-typeのapplication / jsonを持たないJSON APIを使用しても大丈夫ですか？参照をいただければ幸いです。商業的な観点からこの状況をどのように解決しますか？

25 rest  api-design  json  bad-code 

Odataのポイントと、それがいつ意味をなすかを理解しようとしています。今の私の仕事は、ASP.NETとMVC / WebApiコントローラーを使用してオブジェクトをJSONにシリアル化/逆シリアル化し、javascriptに何かをさせることです。 ODataの利点は、URLから直接クエリできることからわかりますが、クライアントコードとサーバーコードを記述しているので、その必要はありません。 誰かがjavascriptでODayaクエリの結果を解析することはありますか？ たぶん、ODataは、JSONが提供しないクエリから詳細な情報を取得するために、すべてのクライアントに汎用エンドポイントを提供することに関するものでしょうか？もし私がデータの提供者だったら、それがodataの目的だと思いますか？ REST / JSON / ODATAの目的と使用法を理解してください。

23 javascript  rest  json 

キーと値のペアに適したJSON形式は何ですか？その理由は何ですか？ [{"key1": "value1"}, {"key2": "value2"}] または： [{"Name": "key1", "Value": "value1"}, {"Name": "key2", "Value": "value2"}] または： {"key1": "value1", "key2": "value2"} 最初のバリアントは、よりコンパクトで、より「意味的に意味のある」ようです。2番目のバリアントは、より均等に構造化されているように見えるため、処理に役立ちます。3番目の亜種はさらに意味がありそうです。 キーと値のペアは、他のアイテムに任意のデータを添付するために使用されます。データをJSONとしてシリアル化して、システムを介してデータをラウンドチップする必要があります。

23 json 

JSONでのロギングに関する記事が増えています。NodeJSブログでも見つけることができます。誰もがそんなに好きなのですか？より多くの操作が関与しているのを見ることができます： いくつかの新しいオブジェクトが作成されます。 オブジェクトの文字列化。文字列の長さを計算するか、複数の文字列を割り当てます。 作成されたすべてのがらくたをGCします。 JSONログと通常の文字列ログを使用するときのパフォーマンスのテストはありますか？人々はエンタープライズプロジェクトでJSON（ロギング用）を使用していますか？

22 logging  json 

これはおそらく、MicrosoftがASP.NET Web APIライブラリを作成したときから始まったものであり、少なくとも私が間違えなければ覚えているときです。とにかく、それ以来、そのHTTPパッケージは、JSONとのデータの（デ）シリアル化のためにNewtonsoft.Jsonライブラリに依存して開始されました。 マイクロソフトと同じくらい大きな会社がオープンソースライブラリへの依存を追加するのはなぜですか？私が知っている限り、それが依存関係として使用される唯一のMicrosoft以外のライブラリだったので、彼らが当時。 おまけの質問として、ジェームズ・ニュートン・キングはマイクロソフトから何らかの財政的支援を受けていますか？

18 .net  asp.net  json  web-api 

私はプロジェクトでフロントエンドの役割を担っています。PHPがJavaScriptに返すJSONの正確な形式をバックエンドチームメイトに指定する必要がありますか？ たとえば、ここで説明する形式と同様の形式を使用する必要があることを伝えます。 フロントエンドで使用するためのJSONを適切に構成する方法 または、自分の役割を可能な限り無菌状態に保ち、単にバックエンドインターフェイスから必要な入力と出力を言葉で説明する必要がありますか？（もちろん、これが発生した場合、異なるデータ構造形式を処理することは私の側でより困難になる可能性があります）

17 development-process  teamwork  interfaces  json  front-end 

JSONがJavaScript Object Notationの略である場合、JSONオブジェクトと言うとき、あなたは本当に「JavaScript Object Notationオブジェクト」と言っているのではないでしょうか？ 「JSON string」と言う方が正しいでしょうか？ それとも、単にJSONと言う方が正しいでしょうか？（「これらの2つのサービスは、それらの間でJSONを渡します」のように。）

15 documentation  grammar  json