Morning Girl

Web API, Windows, C#, .NET, Dynamics 365/CRM etc..

Tesla API の検証環境（物理）が手に入ったので、改めて Tesla API の使い方を解説してみる

今年の1月にこんなエントリーを書いたわたくしですが、

kageura.hatenadiary.jp

5月に少し気を失っていたら、以下のような画面が iPad に表示され

9月末にとうとう Tesla API 検証環境（物理）が届いてしまいました。

上記エントリーでは、ダミーデータを返すモック環境のAPIだったので、常にバッテリーが減らない、いくら操作をしても壊れない夢のような（そしてちょっと寂しい）テスラだったのですが、ちゃんとバッテリーが減るAPIとして試すことができるようになりました！

というわけで改めてこのTesla APIの使い方を解説していきたいと思います！

  • そもそも Tesla API とはなんなのか？
  • Tesla API のちょっと気をつけたいこと
  • Tesla API はどんなことができるの？
  • Tesla API のここが面白い！
  • Tesla API の使い方
    • 認証方法
    • Product IDの特定
    • Tesla の起動
    • 車両のデータを取得してみる
    • ライトの点灯
  • おわりに
続きを読む

LogicApps で Azure Blob Storage に JSONファイルをアップしたり、取得したりする

LogicApps Azure Blob Storage

Azure Blob Storage にAPIから取得したJSONを放り込んでおこうかな―と思って、色々と試していたときのメモです。

JSONファイルのアップロード、JSONファイルを取得して、LogicAppsでオブジェクトとしてハンドリングする方法を書いています。

docs.microsoft.com

対象の環境

Azure Blob Storage、ADSL Gen2でとりあえず構成しました。

Logic Appsで扱う場合、特にADSL Gen2かどうかというのは、問わない感じですが。

以下のjsoncontainerというフォルダにjsonファイルを格納していくイメージです。

f:id:sugimomoto:20201107125238p:plain

JSONファイルの作成

BLOBへのJSONアップロードには、Azure Blob Storageの「BLOBの作成」アクションを使います。

f:id:sugimomoto:20201107125244p:plain

LogicAppsで構成すると、予め対象の環境（たぶんLogicAppsを構成しているサブスクリプションの範囲？）に存在するストレージアカウントがリストアップされるので便利ですね。

f:id:sugimomoto:20201107125250p:plain

フォルダーのパスで構成しておいた、コンテナを選択し、任意のファイル名をつけておきます。

今回は日付を元に「20201107030509.json」のようなファイル名を生成する関数を指定しました。

concat(formatDateTime(utcNow(),'yyyyMMddHHmmss'),'.json')

あとは、BLOBコンテンツにJSONを突っ込めばOKです。

f:id:sugimomoto:20201107125256p:plain

こんな感じで対象のファイルが生成されました。

f:id:sugimomoto:20201107125302p:plain

f:id:sugimomoto:20201107125345p:plain

BLOBからJSONファイルの取得

BLOBにアップロードされたファイルの取得には「BLOBコンテンツの取得」を使います。

f:id:sugimomoto:20201107125358p:plain

本来であれば、一度一覧表示をしてから、ファイルを特定、みたいなプロセスを経ますが、今回は静的に指定。

f:id:sugimomoto:20201107125404p:plain

ただし、注意したいのが出力結果です。JSONフォーマットで$contentのオブジェクトの中に、Base64でエンコードされたBinary形式で入っています。なので、このままではLogicAppsでハンドリングできません。

{
  "$content-type": "application/octet-stream",
  "$content": "ewogICAgIkZpcnN0TmFtZSI6ICJIZWxsbyIsCiAgICAiTGFzdE5hbWUiIDogIldvcmxkIgp9"
}

f:id:sugimomoto:20201107125411p:plain

なので、base64ToString関数を使って、値をデコードします。

docs.microsoft.com

base64ToString(body('BLOB_コンテンツの取得').$content)

以下のように「JSONの解析」アクションに突っ込んでしまうのが良いですね。

f:id:sugimomoto:20201107125418p:plain

これで無事出力できました。

f:id:sugimomoto:20201107125423p:plain

わからなかったこと

「BLOBのコンテンツの取得」にある、「コンテンツタイプの推測」ってなんなんですかね？

f:id:sugimomoto:20201107125428p:plain

スタックオーバーフローにもスレッドを見つけましたが、特に明確な回答はあがっていないみたいでした。

stackoverflow.com

質問者も言っている通り、CSVやJSONを指定して、LogicApps上でハンドリングできるオブジェクトにして返してくれると、嬉しいですよねぇ。

SaaS・クラウド時代におけるバラバラデータへの取り組み方

去年12月5-6日（Tokyo）と今年1月23-24日（大阪）で開催された Microsoft Ignite The Tour に参加してきました。

そこで、同じ Dynamics 365 MVP のカテゴリである吉島さんのセッション「もしも、バラバラ殺データ事件に遭遇したら（裏タイトル）」を見てきたんですが、これがとても示唆に富む内容でした。

https://www.pbc.co.jp/blog/microsoft-ignite-the-tour-tokyo-how-to-describe-our-promissing-future/

f:id:sugimomoto:20200131131710p:plain

顧客管理や生産管理、プロジェクト管理といった各ビジネスプロセス・マネージメントでそれぞれの要素がバラバラに各サービス・アプリケーションに存在した場合、どのような課題、難しさが存在するか？　また、そのソリューションとして考えられるものは何か？　といった点をテーマのセッションです。

f:id:sugimomoto:20200131131716p:plain

2020年となった今、企業の内部はマルチクラウド・マルチ SaaS 時代に突入し、データの在り方、連携の方法が改めて大きな課題として直面しています。

吉島さんのセッションでは、メインとなる部分は「ビジネスプロセス的バラバラデータ」を Dynamics 365 はどのように解決できるのか？　を中心としたセッションでしたが、これは「ビジネスインテリジェンス（BI）」の考え方としても同じことが言えるな、と思いデータドライバーベンダーのエンジニアの視点として今回の記事にまとめてみました。

なぜバラバラデータを解消しなければいけないの？

BI における「バラバラデータ」の一番の問題とは何でしょうか？

まず認識としてはっきりさせておきたい点は「意思決定や判断にドリルダウンが必須」であるということです。

例えば「売上を前年よりXX%アップする」という単純な目標を掲げるとしても、その施策・アクションのために

→売上ってどうなっているんだっけ？ →その売上の顧客の構成ってどうなっているんだっけ？（ERP） →この顧客はどのセールスリードから発生しているんだっけ？（CRM） →この顧客はどうやって流入してきたんだっけ？（MA） →この顧客はどのキャンペーン・Webサイトを見ていたんだっけ？（Web Analytics）

実際の売上のデータを元に、その顧客からその施策までを紐解いていく必要があります。

これが部門最適な時代であれば、各部門ごとでクローズドな判断に任せられたでしょう。しかし、現代はサブスクリプションビジネスに代表されるように分断されたプロセス・部門が連携しながら、サービスを改良し施策を重ねていく時代です。

f:id:sugimomoto:20200131131725p:plain

何か施策を打つ際にそれがマーケティング的施策であったとしても、KPIの結果として現れるのは営業部隊やテクニカルサポートの部隊のデータかもしれません。

顧客に紐づくデータを部門最適では無く、全体視野を持って分析しアクションにつなげる必要があります。

一つの企業で平均20 程度のSaaS を使う時代に

しかし、そこでボトルネックとなるのが、各サービス・アプリケーションでデータがバラバラに存在してしまっている点です。

私達が分析したい対象はCRMやERPではありません。顧客とその顧客の繋がりに発生しているデータを分析したいはずです。

あるリサーチでは, 2015 年に企業内で使用するSaaS の数は8程度であったものが、2017年には平均16のSaaS を使うようになったとのことです。

f:id:sugimomoto:20200131131731p:plain

このレポートは2017年のものですが、弊社のUS チームでユーザーから聞くところでは、すでに1企業あたり平均20程度のSaaS に接続する必要があるというのが実情のようです。

さらに示唆に富むグラフがありましたので紹介します。これは企業内で使われているクラウドサービスの割合を示したグラフですが、File SharelingやFinanceといった王道のクラウドサービスだけでなく、実に多様なクラウドサービスが存在し、それぞれにビジネスインテリジェンスを必要とするデータが格納されています。

f:id:sugimomoto:20200131131737p:plain

https://cloudsecurity.mcafee.com/cloud/en-us/forms/white-papers/wp-cloud-adoption-risk-report-2019-banner-cloud-mfe.html

上記はUSのトレンドですが、日本でもSaaS の活用はトレンドであり、数年後には現在のアメリカのようにひとつの企業が20以上のSaaS を利用し、それらをデータ分析しアクションに繋げるようにすることは必須の状況に至るでしょう。

しかし、そんなバラバラデータに対応するのに何が一番問題なのでしょうか。

分析のために一番の課題となるのは「インターフェース」である

ちょうど今日見た記事ですが、

www.itmedia.co.jp

f:id:sugimomoto:20200131131743p:plain

また、あるレポートでは「データ準備80%、データ分析20%」と言われています。

f:id:sugimomoto:20200131131808p:plain

それだけデータ分析の手前、様々なデータソースからデータを集め、加工し、分析できる状態に準備するまでに大きな時間と手間がかかっています。

データ準備にも様々な作業・プロセスが存在しますが、その中で今最も大きな課題点として上がっているのはデータソースの多様化であり、そしてそれらがそれぞれ保持している「インターフェース」に潜む課題ではないでしょうか。

「インターフェース」の課題とはなんでしょうか？　また、今私達が接しているデータの「インターフェース」はどんなものがあるでしょうか？

数年前であれば私達の身の回りに存在するデータは「MySQL・SQL Server」もしくは「Excel」や「CSV」といった数少ないフォーマットでした。インターフェースもシンプルであり、どんなツールでもとりあえずRDBやCSVが取り込める状況でした。

しかし、下の図を見てもらえば分かる通り、SalesforceやDynamics 365といった業務横断的なユニバーサルSaaSが出始め、それに追従するような形で、MarketoやServiceNow といった部門特化型、そして最近ではMailChimpやExcelOnlineなどの特定シナリオ・特定機能に特化したクラウドサービスが出てきました。

f:id:sugimomoto:20200131131815p:plain

このように業務も機能も幅広く存在するのが現在のクラウドサービスの状況ですが、それに加えて複雑さを増しているのがインターフェースです。

5つのカットで見るデータを扱う難しさ

インターフェースの多様さは大きく5つのカットで捉えることができます。

  • Protocol
  • Data Model
  • Metadata
  • Authentication
  • Capability

まず一番大きなレイヤーでいくと Protocol でしょう。Web APIに接続するのであれば、HTTPレイヤーのプロトコルは必須ではありますが、HTTPレイヤー上で

SOAPは現在主流ではな無くなっていますが、依然 Salesforce・NetSuiteなど重要なパッケージで利用されています。 また、RESTに関しましては今最も主流のAPIデザインですが、あくまでAPIのアーキテクチャスタイルであり、その実装は各API毎で千差万別です。これも単純にAPIというものを捉えることができない重要な要因です。

f:id:sugimomoto:20200131131821p:plain

また、データモデルも多様化しています。上記のように今までであればリレーショナルな形式のみ認識してればよかったですが、NoSQLに代表されるDocument・KeyValue、JSONフォーマットであればネステッドなレイヤーも意識しなければいけません。

f:id:sugimomoto:20200131131827p:plain

さらにデータ分析を行う上で、スキーマは最も重要な要素ですが、残念ながら多くのインターフェース、APIではスキーマが提供されていないのが実情です。

もちろん中にはStaticなモデルであるため、固定的なスキーマを当てはめればいいものもあるかもしれませんが、ユーザーのカスタマイズニーズに答えるようなkintone や Slaesforceといったクラウドサービスでは Dynamics なスキーマ・データモデルがスタンダードです。

f:id:sugimomoto:20200131131834p:plain

更に私達が最も気にしないといけない要素は認証・Authentication部分でしょう。データ分析としては必要のない要素であったとしても、この要素をかいくぐらなければ、私達はデータにアクセスすることすら叶いません。

BasicやNTLM・Kerberosといったスタンダードとなっているプロトコルもありますが、現在のWeb APIではOAuthが主流でしょう。しかし、少しでもセキュリティの意識が高い企業であれば、SSO対応やデバイス証明書の流れを組んでいるものもあります。

f:id:sugimomoto:20200131131840p:plain

最後に私達は各Web APIスペシフィックなインターフェースの機能に対応しなければいけません。

例えば世の中に数多く存在するWeb APIは、ほとんどが集計処理に対応していません。またエンティティ、リソース同士をJoinすることもできませんし、特定カラムのみしかフィルターをサポートしていないというのも日常茶飯事でしょう。

f:id:sugimomoto:20200131131847p:plain

上記にあげたのは全体像を捉えるためのキーワードの羅列にすぎませんが、私達はこういった要件を制約を機能をかいくぐりながら、マルチクラウドサービス。マルチSaaSの時代をデータドリブンしていかなければいけません。

では、私達はいかにマルチSaaS・マルチクラウド時代のデータ分析基盤を整えるべきか？

おそらく大変のエンジニアであれば、APIの一つや2つの連携実装くらい、どうということは無いでしょう。

しかしながら、前述の1企業あたりにおけるクラウドサービス・SaaSの利用拡大を踏まえると、一つ一つ手動で作り込みをしていたら、追いつかない状況になっている状況であることは明確です。

用途やプラットフォームに合わせて連携アプローチを変えていく必要があります。 如何に低コストで膨大なデータを活用するか？

・インターフェースを整えてくれるツールを最大限に活用すること。 ・扱いやすいデータ基盤に投入すること。

「素早くローディングし、アドホックに分析できる環境を整えること」

そういった際にELTツール（データプレパレーション）とDWHの連携、データマートとしてBIツールを使うのが現在のスタンダードです。

  • CDataSync
  • Azure DataFactory
  • Power BI DataFlow
  • AWS Glue
  • Google Data Fusion
  • Tableau Prep
  • Embulk
  • Talend

ELT的 Dynamics 365 アプローチ：業務担当者が接しやすいBI

そんな中で最近特に興味深い Dynamics 365 的アプローチがありましたので紹介したいと思います。

それが「Dynamics 365 / PowerApps CDS のデータフロー機能」です。

f:id:sugimomoto:20200131131856p:plain

https://docs.microsoft.com/ja-jp/powerapps/maker/common-data-service/create-and-use-dataflows

データフローでは Dynamics 365 / CDS へ簡単に Access や SharePoint リストなど30種類ほどの外部データを簡単に取り込める機能です。

f:id:sugimomoto:20200131131902p:plain

何がいいかと言えば、データフローで取り込んだデータは Dynamics 365 のデータモデルとして直接扱うことができる点です。

通常はマスタデータ同期であったり、名刺データの取り込みといったアプローチに使われることが多いのですが、データモデルとして扱えるということは、顧客と関連付けてDynamics 365のデフォルトダッシュボード機能などで分析やアクションに繋げることができるというのが大きなポイントです。

f:id:sugimomoto:20200131131907p:plain

また、データフローはODBCの接続をサポートしており、CData ODBC Driver を組み合わせることで、200種類のデータ接続先をカバーすることが可能になります。

www.cdatablog.jp

f:id:sugimomoto:20200131131919p:plain

例えば、以下の画面は Google Analytics から各コンテンツのPVを Dynamics 365に連携したものです。Dynamics 365にはマーケティングのモジュールもあるため、マーケティング施策がフィードバックとして適切にサイト流入にも反映されているかどうか、といったところが一つのインターフェースで見れるようになります。

f:id:sugimomoto:20200131132029p:plain

まとめ

世の中のデータは指数関数的に増えていますが、それ以上に多様なインターフェースが存在し、その複雑さが顕著になってきています。

直近のデータ連携のトレンドとしても、データ加工や安定的な稼働よりも、データ接続先の多様さが連携ツールに求められてきていることがわかります。

f:id:sugimomoto:20200131132358p:plain

www.cdatablog.jp

スケーラブルかつ柔軟なDWHが増えて、データ加工の処理コストが大きく下がり始めている今、注力するべきはバラバラデータを如何にコストパフォーマンスよく収集することではないでしょうか。

f:id:sugimomoto:20200131132642p:plain

様々なツールをうまく活用し、一つ一つ手組ではなく、全体効率として適切なアプローチをとっていくことが今後ますます重要になってくると思います。

スマレジ API のリクエストを簡単に作成するためのAPIテストエクスプローラーを作った

Blazor スマレジ API C#

https://github.com/sugimomoto/SmaregiAPP.APIExplorer.Blazor/raw/master/SmaregiAPP.APIExplorer.Blazor/wwwroot/img/smaregi.gif?raw=true

最近ちまちま個人的に作っていた「スマレジ API のリクエストを簡単に作成するためのAPIテストエクスプローラー」を公開してみました！（APIの基本的な使い方はこちらをどうぞ）

以下のURLで公開していますので、スマレジ APIを試してみたいけど、ちょっと敷居が高そう、、、みたいな人は是非試してみてください。（そしてフィードバックをください！）

smaregiapiexplorer.azurewebsites.net

ちなみに、現在はデータ取得部分のみ対応しています。要望が多ければデータ作成・更新部分も対応しようかなと考えています。

使い方は動画や中身を見ればわかるかなーと思いますが、こちらも参照してみてください。公開したばかりで色々とあると思いますが、何かあればIssueまで。

github.com

そもそも、なんでそんなものを作ったの？

スマレジAPI以下の図で示している通りすごく高機能かつクエリの自由度が高いんです！　ほとんどのパブリックなAPIってOrderByができなかったり、フィルターが特定の項目だけだったりするんですが、スマレジではほとんどすべての項目に対して柔軟にクエリを行うことができます。

f:id:sugimomoto:20200217233743p:plain

でも、データ取得のリクエスト方法が結構独特のフォーマットで、できることが多い分、若干ツラミがあります。

f:id:sugimomoto:20200217233846p:plain

そこで、そんなデータ取得のリクエストを簡単に作成できるエクスプローラーがあればいいなー、（ついでに今試しているBlazorで作れたら面白そうだなー）と思い、作ってみました。

リクエストを作成した後は、そのままPostmanやプログラムでのリクエストにも貼り付ければ、そのまま利用できます。

f:id:sugimomoto:20200217234313p:plain

もちろん、エクスプローラー上でそのままテストもできます。

技術スタック的な

ASP.NET Core C# Server side Blazor （.NET Core 3.0）ですべて作成しました。

docs.microsoft.com

ホスティング先は Azure Web Apps です。

クライアントロジックがすべてC#で書けるのはやはりいいですね・・・！　まだ、触り始めたばかりですが、すごく可能性を感じます。

開発にあたって @jsakamoto さん、@piyo_esq さんには大変ありがたいアドバイスを頂きました。

qiita.com

途中うまくフォームデータを取得しきれない部分があり、JavaScriptで泣く泣く対処していたんですが、最終的には全部ちゃんとC#側にロジックを寄せることができました。大感謝！

その他宣伝的な

あと、私の会社では以下のようなスマレジを便利に使うためのソフトウェアも提供しています。

この時の開発経験がこのエクスプローラーの開発でもかなり役立っています。結構面白いことができるので、トライアル等を是非試してみてください。

CData Smaregi Driver

cdataexcel

スマレジデータをExcel から操作　Product （製品）マスタを一括編集

Tableau Desktop で スマレジ の売上データを可視化

スマレジの商品データと取引データを BigQuery に日次で連携

ノーコードツールでスマレジの会員データを kintone の顧客リストに連携：CData Smaregi Driver & ArcESB

.NET C# クエリビルダー SqlKata で CData ADO.NET Provider for kintone を使ってみる

SqlKata CData ADO.NET kintone

ちょうど先日、Twitterでこんな疑問を見かけました！（ありがとうございます）

雰囲気行けそうな感じだったので試してみたら、すんなり接続できたので、Blogとしても書き起こしてみました。

SqlKataとは？

オープンソースで提供されている ADO.NET ベースのクエリビルダー兼ORMのライブラリです。

sqlkata.com

通常のSQL Server アクセス

まず、通常通りの使い方で、SQL Serverにアクセスしてみました。なお、.NET Frameworks でやっていますが、.NET Coreでもほとんど変わりません。

Consoleアプリケーションを作成し、Nugetでパッケージをインストール。

Install-Package SqlKata Install-Package SqlKata.Execution

以下のテーブルからデータを取得します。サンプルデータのAdventureworksに含まれているPersonテーブルを対象にしています。

f:id:sugimomoto:20200207105710p:plain

今回は単純にPersonテーブルからの取得を作成してみました。メソッドチェーンで指定できるのがいい感じです。

内部にはDapperが使われているようで、データをGetする際に指定のクラスを渡してあげればIenumerableでレスポンスを受け取れます。いいですねー。

gist.github.com

f:id:sugimomoto:20200207105755p:plain

Select・Where・OrderByといった要素も以下のようにメソッドチェーンで記述できて、大変楽です。

            // Where
            persons = db.Query("Person.Person").Where("BusinessEntityID", "1").Limit(10).Get<Person>();

            // SELECT
            persons = db.Query("Person.Person").Select("BusinessEntityID").Limit(10).Get<Person>();

            // OrderBy
            persons = db.Query("Person.Person").OrderByDesc("BusinessEntityID").Limit(10).Get<Person>();

CData ADO.NET Provider for Kintone を利用する方法

次に「CData ADO.NET Provider for Kintone 」でも試してみたいと思います。事前に以下のページからトライアルをインストールしておきます。

https://www.cdata.com/jp/drivers/kintone/ado/

f:id:sugimomoto:20200207105817p:plain

インストール後、対象のプロジェクトに以下のDLLを参照しておきます。

C:\Program Files\CData\CData ADO.NET Provider for kintone 2019J\lib\System.Data.CData.Kintone.dll

対象となる kintone のアプリは以下のようなテンプレートで作成できる案件情報です。

f:id:sugimomoto:20200207105829p:plain

一点、kintone を扱う上で注意したいのは、取得できる項目名が「日本語」であるという点ですが、なんと素晴らしいことに、ちゃんと日本語名で定義したClassにデータをマッピングすることができるようになっています。

gist.github.com

f:id:sugimomoto:20200207105836p:plain

Insertもこの通り。素晴らしいですね。

            var query = new Query("案件情報").AsInsert(
                new
                {
                    案件名 = "ugauga"
                }
                );

            db.Execute(query);

余談

CData ADO.NET Provider では LINQもサポートしています。このあたりは好みに合わせてライブラリを選ぶことができますし、

cdn.cdata.com

ADO.NET ベースで実装されているラッパーライブラリであれば、だいたいいけると思います。

過去にはDapperでの接続も検証していました。

kageura.hatenadiary.jp

Reference

tekitoumemo.hatenablog.com

ミルクボーイが REST API を説明したら

REST コラム API

f:id:sugimomoto:20200131171318p:plain

序章

駒場「最近、うちのおかんがシステム開発に興味を持っててなぁ、名前は忘れたらしいんやけど、色んなクラウドサービスのインターフェースになっていて、アプリケーション間連携にすごく役立てられるものを取り入れてるところがあるらしいんやわ〜。」

内海「そんなもんREST APIに決まってるがなぁ！ 今やクラウドサービス連携に必須の要素、インターフェースと言えば、REST API。ロイ・フィールディングが提唱し、WEBやURIの特性・HTTPプロトコルを最大限に活かしたアプリケーションプログラミングインターフェースのスタンダードになっているREST APIに決まってるがなぁ。」

すべての情報（リソース）に適用できる「よく定義された操作」のセット

駒場「最初、オレもそう思たんやけどな、なんでもHTTP Body にInsertとかCreateとか入ってるらしいんやわ。」

内海「ほなぁ、REST APIちゃうかぁ…。REST API は HTTP メソッドで予め定義されているGETやPOSTを利用するのがスタンダードやからなぁ。それはRPCのプロトコルであるSOAPとかちゃうんの？　おかん、他にもなんか言うてなかったかぁ。」

リソースを一意に識別する

駒場「そー言えば、URIを意識して作ってるって言うてたわ。」

内海「ほな、REST APIやないのぉ。 REST API ってことは、リソースを一意に識別するためのURIが重要で、users や products とかの名詞で構成するのがスタンダードやからなぁ。やっぱ、REST API やろぉ。」

駒場「オレもそう思たんやけどな、URI にも getUsers とか postPoroduct とか動詞が含まれていて、全部POSTリクエストで実装しているらしいねん。」

内海「ほな、REST API と違うかぁ。リソースは一意になっても、HTTPのメソッドを活用してないからなぁ。やっぱりRPCのプロトコルのSOAPとかちゃうんの？　他にもなんか言うてなかったぁ?」

ステートレスなクライアント/サーバープロトコル

駒場「おかんが言うにはな、ステートレスでやっているらしいわ。」

内海「ほな、REST API に決まってるがなぁ。REST APIは、HTTPメッセージの一つ一つが、そのリクエスト（メッセージ）を理解するために必要な全ての情報を含んでメッセージ間におけるセッション状態を記憶しておく必要がないようにしているから、やっぱREST APIやろぉ。」

駒場「オレもそう思たんやけどな、なぜか商品情報登録のために3つのリクエストを順番に実行しないといけないらしいねん。」

内海「ほなぁ、REST APIとはちゃうなぁ。 サーバーとクライアントの通信で状態を管理してしまったら、サービスがスケールしづらくなるし信頼性、結合度の点でもよくないもんなぁ。やっぱりREST API とちゃうがなぁ。」

アプリケーションの情報と状態遷移の両方を扱うことができる「ハイパーメディアの使用」

駒場「おかんが言うにはな、 ハイパーメディア ってゆーのを取り入れているらしいわ。」

内海「そしたら、やっぱりREST APIやろぉ。通常のWebサイトと同じようにハイパーメディアでリソース間の繋がりが構成されていて、クライアントはリソース名をしらなくても辿ることができるようになっているんは常識やもんなぁ。やっぱ、REST APIやろぉ。」

駒場「オレもそう思たんやけどな、Excel 仕様書にリンクを書くってゆーてたわ。」

内海「ほな、絶対にREST APIとちゃうがなぁ！　ハイパーメディアといえばハイパーメディアだけど、それはREST APIじゃなくてきっと神EXCELやがなぁ！」

結末

駒場「おとんがゆーにはな、GraphQLちゃうか? ってゆーねん。」

内海「それも絶対ちゃうやろ！Facebookに失礼や！ もうええわ！」

ありがとうございましたー

（ご意見、ここが違うんじゃね？　などお待ちしています。）

参考文献

ja.wikipedia.org

www.infoq.com

www.ics.uci.edu

Tesla API（Mock）カスタムコネクタを作成する：PowerApps / PowerAutomate

PowerApps カスタムコネクタ OpenAPI Swagger Tesla API

最近あまりにも Tesla API を触りたい衝動が抑えきれず、 Mock の API Serverを作りました。作り方は以下の記事で公開しています。

kageura.hatenadiary.jp

この Mock Server ですが、実装はOpenAPI で作成していますので、PowerApps/ PowerAutomateのコネクタとしても利用できます。

結構色んなコマンドが用意されていて面白いので、実際に試してみました。

  • どんなことができるようになるの？
  • カスタムコネクタの作り方
    • カスタムコネクタの作成
    • カスタムコネクタを使ってみる
  • 実際に Tesla に接続する場合
    • URLの設定
    • AccessTokenを取得する
    • 認証の設定
  • おわりに
続きを読む