Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? これは Enchant の開発者である Vinay Sahni さんが書いた記事「Best Practices for Designing a Pragmatic RESTful API」1を、ご本人の許可を得て翻訳したものです。 RESTful な WebAPI を設計しようとすると、細かなところで長考したり議論したりすると思います。また、他の API に倣ってやってはみたものの、本当にそれでいいのか、どうしてそうしているのか分からない、何てことも少なくはないと思います。 この記事では、そのようなハマリどころについて Vinay さん
🔧 Maintenance Mode Notice This library is now in maintenance mode. While it remains stable and functional, active development has moved to Jedison. We will continue to: Accept and review community pull requests Address critical bugs and security issues Keep the library functional for existing users For new projects or those seeking active development, consider using Jedison. Fork of the inactive
VOYAGE Lighthouse Studio の海老原 (@co3k) です。先日 30 歳になった記念としてタイトルはオヤジギャグです。 さて、普段は 神ゲー攻略 というゲーム攻略サイトを運営しているのですが、とある派生サービスを立ち上げるにあたり、 Web API スキーマ定義を gRPC に基づく形式の Protocol Buffers で書き、 protoc-gen-swagger プラグインを介して OpenAPI 定義ファイルとして生成する、というアプローチを採りました。 yugui さんの素晴らしい記事、「今さらProtocol Buffersと、手に馴染む道具の話」によってスキーマ定義言語としての Protocol Buffers がにわかに注目を浴びて以降、似たようなことをやりたいという方もいらっしゃるのではないでしょうか。 ところが、おそらく単体で protoc-g
会社のブログに書こうと思ったんだけど、ちょっとマイナスイメージを持つ人もいそうな気がしたので、個人ブログに書くことにした。 この3ヶ月くらい、システムのリニューアル(アプリ間で分散したロジックを集約するバックエンドサーバと、用途に応じたフロントエンドサーバを立てるみたいなマイクロサービス構成)をやっていて、そこでサーバ間のやりとりにgRPCを使っていた。すごーく雑な絵を書くとこんな感じです。 しかし、最近になってプロジェクトのスコープについて見直しが入りました。マイクロサービス化ではなく単純にレガシーJavaで独自FWなアプリをリプレースするだけになり、必要なのはSPAとSpringBootのAPIサーバだけに(要するにRails側のロジックをなんとかするのがスコープ外になった)。 で、SPAに提供するAPIのためにgRPC(+ grpc-gateway)を使うのはちょっとオーバースペック
はじめに こんにちは！モバイルアプリサービス部の加藤です。 今回はC#でJSONを扱う方法について書いてみたいと思います。 C#でJSONを扱う方法はいろいろありますが、 DataContractJsonSerializer Json.NET DynamicJson あたりがよく知られたメジャーな方法だと思いますので、これらについてまとめてみたいと思います。 開発環境 Visual Studio for Mac Preview 1(7.0 build 347) .NETコンソールプロジェクト ターゲットフレームワーク Mono / .NET 4.5 DataContractJsonSerializer DataContractJsonSerializerとは .NET Frameworkで提供されている、オブジェクトをJSONにシリアライズ、JSONをオブジェクトにデシリアライズするための
![[C#] C#でJSONを扱う方法まとめ | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/feea38aafce1adb12366ab5e78f0436ff45e3a8f/backend=imagemagick;height=288;version=1;width=512/https%3A%2F%2Fproxy.goincop1.workers.dev%3A443%2Fhttps%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2016%2F12%2Fcsharp.png)
We’re getting things ready Loading your experience… This won’t take long.
軽い気持ちで投稿したら、思わぬ反響を頂いたこの話。 賛否両論で色々な意見を頂きました。 問題点も含めてある程度メリット・デメリットが見えてきたので、最後にまとめてみます。 ブコメ、Twitterで色々と意見を頂いた方々ありがとうございました。 この場を借りてお礼申し上げます。 前回までのおさらい クライアントとサーバー間で何らかのデータの受け渡しをする時に、 よく使われるフォーマットとしてJSONやXMLがあります。 構造がシンプルなテキストで汎用性が高いため、あらゆるプラットフォーム間の差異を吸収するフォーマットとしてメジャーな存在です。 モバイルアプリも例外ではないのですが、JSONなどを使わずにSQLiteのDBファイルを直接渡してやりとりするというのが先日書いた記事です。 SQLiteはクロスプラットフォームな上に1ファイルで完結するので、1つのファイルで様々なプラットフォームから
animane.hatenablog.com 前回の記事が予想以上に反応を頂いたので、少し補足します。 ユースケース 記事中ではあまり書いていなかったのですが、基本的に参照系のデータが対象になります。 サーバー側で生成しておいたDBをそのまま使う形です。 なので更新系のデータについては別DBに保存してます。 SQLiteのATTACH DATABASEを使えば、異なるDB(別のファイル)でもJOINが使えるので、 CoreDataで作ったSQLiteのファイルも問題なく扱えます。 ただ、DBのサイズが大きくなりすぎると通信に時間が掛かり過ぎるため、 そのような場合は従来通りAPI経由でJSONなりXMLを使う方がよいです。 他にも日本のネットワーク環境を前提にしているので、通信が遅い環境では別の配慮が必要になります。 あと、ブラウザでは残念ながら使えないと思います。 SQLiteのDBをD
アニマネの内部ではアプリとサーバー間でどのようにデータを受け渡ししているかという話をしてみます。 一般的にアプリとサーバー間のデータの受け渡しだとJSONやXML、YAMLなどが多いと思います。 ここにSQLiteという選択肢を入れると色々幸せになれるという話です。 もはや何で今までJSONという固定観念が捨てられなかったのかというぐらい、個人的にはコロンブスの卵でした。 あまり事例はなさそうなので、ここで紹介してみます。 アニマネでの問題点 アニメアプリのアニマネでは主にアニメの番組表やニュースをサーバーから受け取って表示しています。 都道府県にもよりますが、一つの都道府県の1週間分の番組表（アニメだけ）をJSONにすると大体750KBぐらいになるんですね。 これを開発初期ではMessagePackに置き換えてました。 話の本筋とは関係ないですが、JSONよりはMessagePackの方
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
