API / EXTERNAL INTEGRATION

API・外部連携、
コードだけ見ても
つながらなかった。

REST API、JSON、SOAP、 AmiVoice、RESTlet、SFTP。

案件ごとに使う仕組みは違いました。

でも、 外部連携で困ったときに見るところは 少しずつ共通していました。

何を送っているのか。
どこまで届いているのか。
何が返ってきているのか。

APIの書き方だけではなく、 システムとシステムの境界を どう追ってきたかを整理します。

INTRO

最初は、
「APIって何をしてるんだ?」 からだった。

APIという言葉自体は 開発の中で何度も出てきました。

でも最初の頃は、 コードの中にある処理を呼んで、 何かデータが返ってくる、 くらいの感覚でした。

実際に外部システムとの連携を触ると、 それだけでは足りません。

どこへ送っているのか。

何を送っているのか。

認証はどうなっているのか。

相手から何が返ってくるのか。

エラーになったら どちら側を見るのか。

APIはコードの一部分ではなく、
システム同士の境界にあるもの。

そう考えるようになってから、 外部連携の見え方が変わりました。

EXPERIENCE

実務で触った、
外部連携。

案件ごとに仕組みは違いましたが、 システム同士をつなぐ処理を いくつかの形で経験しました。

REST / JSON

REST API / JSON

リクエストを送り、 JSONを受け取り、 必要な値を処理する。 外部連携で何度も触った形です。

AMIVOICE

AmiVoice API

カスタマーサポートシステムで、 音声認識の結果を 業務画面へつなぐ処理を触りました。

SOAP

SOAP連携

Windchillの開発では、 RESTだけではなく SOAPを使った連携にも触れました。

NETSUITE

RESTlet

外部から受け取ったデータを NetSuite側で検索・照合し、 レコードへ登録・更新しました。

FILE INTEGRATION

SFTP

APIで直接つなぐだけではなく、 SFTPサーバーを介した ファイル連携も扱いました。

TEST / DEBUG

Postman / APIDOG

APIをコードから切り離して直接叩き、 request、response、statusを見ながら 問題を切り分けました。

WHAT I LOOK AT

APIが動かないとき、
どこを見る?

外部連携でエラーが起きると、 最初はコードの中から 原因を探していました。

でも、 コードが正しくても 連携できないことがあります。

  • 接続先URLは正しいか
  • HTTPメソッドは合っているか
  • Headerは必要なものが入っているか
  • BodyのJSONは想定どおりか
  • 認証情報は正しいか
  • Requestは相手まで届いているか
  • Responseは返ってきているか
  • Status Codeは何か
  • 相手側でエラーになっていないか

「APIが動かない」 では範囲が広すぎる。

どこまで正常なのかを確認して、 一つずつ範囲を狭めていくようになりました。

RELATED EXPERIENCE

APIだけでは終わらない、
外部連携。

外部システムとの連携は、 REST APIだけではありませんでした。

NetSuiteではRESTletを使って 外部からJSONを受け取る。

ファイル連携なら、 SFTPサーバーを介して CSVを受け渡す。

Windchillでは、 SOAPを使った連携にも触れる。

入口は違っても、 問題が起きたときに考えることは似ていました。

データはどこから来て、
どこを通って、 どこで止まっているのか。

システム間の境界を見ることが、 外部連携ではかなり重要でした。

NetSuite RESTletで外部データを受け取った話 →

SFTP連携を外から確認しながら切り分けた話 →

FIELD NOTE

APIを覚えたというより、
「間を見る」ようになった。

APIを触り始めた頃は、 リクエストを送って レスポンスを受け取れれば それでいいと思っていました。

でも、 実際の業務システムでは その間にいろいろなものがあります。

認証。

データ形式。

接続先の設定。

相手側の処理。

SFTPなどの中継。

そして、 その先の業務処理。

システムとシステムの間で 何が起きているのかを見る。

APIや外部連携を触ったことで、 コードだけではなく データがシステム間をどう流れているのかまで 見るようになりました。