個人開発で「Excel専用のWebAPI」を作りました
どういうもの？ このように関数を使ってデータを取り込めます。 背景 元々は「インターネット上のWebAPIのデータをExcelに取り込みたい」と思ったのがきっかけです。 VBAマクロを使えば簡単ではありますが、マクロは使いたくないという方も多いのではないでしょうか。かくいう私も勤務先が属人化を防ぐためにマクロの使用を推奨していません。 そこで、関数を使用する方法を選択しました。 ExcelにはWEBSERVICE 関数という指定したURLの応答データを取り込む関数があります。 しかし、この関数は大変便利な関数ですが、ExcelはHTMLやJSONのパーサーを用意していません。結局取り込んだHTMLやJSONの処理にはVBAマクロが必要になります。 また、欲しいWebAPIが存在しない問題もありました。 そこで、Excelでデータを編集するのではなく、元々のWebAPIをExcel用に作れば
非同期処理に疲れた方に、ReactQueryの処方箋
この記事について 本記事は、下記のReactQuery公式ドキュメントの内容をベースに、自分なりに噛み砕いてまとめたものになります。 ReactQuery公式ドキュメント サンプルコードの一部は公式サイトから引用しています。 前置き 【呼称について】 ReactQueryはSolidやVue、Svelteへの対応を進めており、現在の正式な名称はTanStackQueryになっています。 ReactQueryの方が耳馴染みのある方も多いため、この記事では、ReactQueryと呼ぶことにします。 【内部実装のイメージについて】 以下、「内部実装のイメージ」となっているアコーディオンの箇所は、ReactQueryの内部実装が実際にそうなっているということではなく、 「こういうふうなコードをイメージすると理解しやすそう」という意図で書いています。 基本的には読み飛ばしていただいても大丈夫な箇所で
webフロントエンドからwebAPIを呼び出すのをwrapするアレの名前 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
twitterに書いたやつ再掲+加筆。 Webフロントエンド、というかSPAの設計で、単なるwebAPIラッパーに対して「Repository」と名付けるケースが散見されるけど、ぼくはあれあまり好きではないです。というのも、Repositoryという名前がついてると、集約的なもの、それが言い過ぎならいわゆるEntity、それも言い過ぎならひとかたまりのデータを保存、取得するだけの責務のように思えるからです。けど、実際の「Repository」を見てみると、取得されるのは画面の仕様にベッタリなJSONだったり、更新系としてもなんちゃらidとパラメータを渡すようなIFになってることが多いですよね。画面の仕様にベッタリなJSONが返ってくるようになってたり、idとパラメータ渡すだけだったりするのは、多くの場合考えることが少なくて済むし通信量も減る良いプラクティスだと思うので、それ自体は問題ではな
アプリクライアントがリソース指向なサーバAPI設計に期待すること - Qiita
酔いどれ設計ナイト2019 - connpassの発表資料です。 イベントのテーマ 「DB設計とAP設計をつなぐナニカ」 ということでこの記事では、アプリケーションサーバの利用者であるクライアントの視点から、どういう構造が嬉しいのか語ります。 自己紹介 iOSアプリ設計パターン入門という本の前半で、「設計とは何か」という主語の大きい話をしたり、GUIアーキテクチャの40年の歴史をまとめたりしました 題材をSwiftに絞っただけで、内容としては他プラットフォームにも通用する感じのやつなのでよかったらおひとつどうぞ Qiitaだと、お前らがModelと呼ぶアレをなんと呼ぶべきか。近辺の用語(EntityとかVOとかDTOとか)について整理しつつ考える - Qiitaという記事がよく読まれてます 議論の前提 今回の議論にはいくつかの前提があります。 クライアントチームとサーバチームが充分に協調し
Spring Boot + GraphQLでAPIを作成してみよう！ - Yahoo! JAPAN Tech Blog
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog はじめに こんにちは、コマース福岡開発部で金融サービスのバックエンドを担当しているチョ ジョンミンと申します。 「Yahoo! JAPAN Tech Advent Calendar 2018」に寄稿させていただく機会をいただきましたので、前から興味のあったGraphQLのAPIを実装してみました。本記事では、GraphQLの概要とAPIの作り方を紹介します。 ターゲット 本記事は、次の読者を想定して書かれています。 GraphQLに興味はあるが、作成した経験がない方 Spring BootでGraphQLのAPIを作成してみたい方 目次 利用している技術 GraphQL概要 GraphQLのメリットとデメリット GraphQLのA
GraphQLを導入しようとしている話
こんにちは。Studyplusでサーバーサイドを担当している金澤です。 弊社ではいまapiの一部にGraphQLを導入するべく取り組んでいます。 GraphQLってなんだという話や導入手順などはweb上にすでに沢山あると思います。 なのでそのへんはあっさりめで、検証にあたってどのような実装をしているかという話をします。 で、GraphQLってなんだ 公式ページから言葉を借りれば、 A query language for your API です。 apiに対する問い合わせをクライアントで組み立てて柔軟にできます。 上記ページのデモがとても分かりやすいのでピンと来ない方は是非ご覧ください。 GraphQLでできる3つのこと query データの問い合わせ 今回はこの話だけします mutation データの変更 subscription いわゆるpub/sub なぜGraphQLなのか 動機と
RESTful API設計におけるHTTPステータスコードの指針 - Qiita
RESTful APIを設計した際のステータスコードの指針です。 メソッド別 GET 成功した場合 200 OK：最も一般的 304 Not Modified：条件付きGETでキャッシュを使わせたい場合 POST 成功した場合 201 Created 作成したリソースのURIを示すLocationヘッダを付けておく 議論 200 OKだとまずいのか？ 200 OKを応答する実装も多くあり、まずいというわけでもない 200 OKはPOST結果がキャッシュ可能、201 CreatedはPOST結果がキャッシュ不可能として分けてもいいが、そこまでする必要があるか？（POSTのキャッシュは一般的ではない） 204 No Contentだとまずいのか？ クライアントがPOST結果を事前に全て知っているわけではないのでNo Contentは不親切では？ 失敗した場合 409 Conflict：作成しよ
GraphQLは90%のウェブサービス開発者にはまだ時期尚早ではないか - Qiita
PySpa統合思念体です。チャットで話をしたことのまとめです。何人かで雑に話をしたことのまとめで、特定の誰かの発言というわけではなく、一種の怪文書です。 さて、GraphQLが世間を賑わせ始めています。Facebookが開発し、GitHubも機能提供をし始めました。GraphQLはRESTの未来か？みたいな論調もありますが、新しいものが出てくると既存のものをサンドバックにして「まだそんな古いの使ってやがるのかよwwwww」みたいな煽りをするのはもはやウェブ界隈の風物詩になっていますが、そういう信者発言をして「ああ、あいつまた踊らされてるな」「あいつ技術を見る目がないな」みたいに思われないように、少し冷静にGraphQLの立ち位置や、今後予想される流れについて考えてみます。 LSUDsとSSKDs WebAPI The Good Partsでも紹介されていた概念として、Netflix社のAP
WebAPI でファイルをアップロードする方法アレコレ - Qiita
WebAPI を開発していると、ファイルを扱いたい場面に出くわすこともあると思います。 ただ、いざ WebAPI にファイルアップロードの仕組みを入れようとすると、いまいちしっくり来る方法がわからず、悩んだりするのではないでしょうか。 今回は実サービスの例を踏まえつつ、どのような方法が使われていて、何がベストプラクティスなのかを検討しようと思います。 ファイルの送信方法 モダンな RESTful WebAPI では、だいたい JSON でデータがやりとりされていると思いますが、この中にファイルの概念を入れようとすると、特に Input（ファイル送信）のやり方に悩むのではないかと思います。 世の中の WebAPI をざっと見てみると、ファイル送信については主に「multipart/form-data」と「Base64 エンコード」のどちらかが使われていることがわかります。 では、それぞれの特
「WebAPI 設計のベストプラクティス」に対する所感 - Qiita
「翻訳: WebAPI 設計のベストプラクティス」を読んで色々と思うところがあったので書きました。 上記の記事は訳文でありますので、正しくは「Best Practices for Designing a Pragmatic RESTful API」に対する所感と述べた方が良いのかもしれませんが、日本語で通して読めるよう Qiita に投稿された訳文に対する所感として書いています。 以下では「翻訳: WebAPI 設計のベストプラクティス」並びに「Best Practices for Designing a Pragmatic RESTful API」は「当該記事」と表現します。 観点 当該記事では「○○とした方がよい」との意見に対してそうすべき理由が明らかになっていないか、もしくは表現が曖昧な場合が目立っていると感じました。設計は実装のようにプログラム言語仕様が制約を与えられないため、意図
翻訳: WebAPI 設計のベストプラクティス - Qiita
これは Enchant の開発者である Vinay Sahni さんが書いた記事「Best Practices for Designing a Pragmatic RESTful API」1を、ご本人の許可を得て翻訳したものです。 RESTful な WebAPI を設計しようとすると、細かなところで長考したり議論したりすると思います。また、他の API に倣ってやってはみたものの、本当にそれでいいのか、どうしてそうしているのか分からない、何てことも少なくはないと思います。 この記事では、そのようなハマリどころについて Vinay さんなりの答えを提示し、簡潔かつ明快に解説してくれています。 今後 WebAPI を設計される方は、是非参考にしてみてください。 なお、誤訳がありましたら編集リクエストを頂けると幸いです。 まえがき アプリケーションの開発が進むにつれて、その WebAPI を公
まだAPIで消耗してるの？ サクッとデータが欲しいなら「Blockspring」を使おう！ – GUNMA GIS GEEK
各サービスのAPIの仕様なんて覚えてらんねぇ！という人は是非。 Blockspringとは Blockspringは、TwitterやFacebookなどのソーシャルメディアをはじめ、Amazon、Youtubeなど様々なサービスからのデータを、プログラマがAPIを直接触ることなく表データとして取得することができるサービスです。サービスごとに規格の異なるWebAPIを利用するには学習コストが結構かかるわけですが、Blockspringはそういったサービスとプログラマーの間に立ち、データ取得のインターフェイスを抽象化してくれます。 非常に沢山のサービスに対応しています。 「ちょこっとデータが欲しいだけなのに、サービス毎のWebAPIを勉強するのもう疲れた」 そんな時はBlockspringを利用してみてください。 インストール BlockspringはGoogle スプレッドシートとエクセル
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
はじめてのGraphQLスキーマ設計
HTTP API の設計方向