[B! api][開発] wate_wateのブックマーク

オープンソース住所正規化エンジンを地番住所に対応したメジャーバージョンをリリースしました！

Geolonia がオープンソースで公開している住所正規化エンジン normalize-japanese-addresses のバージョン 3 を公開しました。住所マスターの更新これまでのバージョンでは、国土数値情報や郵便局データを使った住所マスターをベースに動作していました。今回のバージョンでは、住所マスター自体も更新しております。具体的には、デジタル庁が公開しているアドレス・ベース・レジストリ（ABR）を元に作り直しました。これにより、正規化できる住所の網羅性、精度の向上、更新頻度の安定化が期待されます。デモサイトのご案内新バージョンを早速お試しいただけるデモサイトをご用意しました。ぜひご利用ください。デモサイトはこちら出力形式の変更点 v3 へのアップグレードの際には、出力形式が変更されているためご注意ください。 v2 はそのまま利用いただく場合は出力形式が変わりません

wate_wate 2024/10/12

リンク

個人で動作を試せる銀行系オープンAPIまとめ - Qiita

オープンAPIの活用ということで銀行も積極的に動き始めていますが、一般の開発者向けに公開されている情報は少ないというのが現状です。2019年7月時点で、個人にも情報公開されていて、実際に動作を試すことのできる銀行系APIをまとめました。 ※いずれもあくまで開発環境で動かすというもの。本格利用には申請と審査が必要です。三菱UFJ銀行三菱UFJ銀行 API開発者ポータルアカウント登録要。利用できるサービスは個人向けと法人向けの2種類。個人向けは参照系のみ。法人向けに更新系が用意されています。サンプルコードはCurl,Ruby,Python,PHP,Java,Node,Go,Swift で用意されています。個人API 口座API　…口座の残高や入出金明細が取得できる。顧客API　…お客様情報が取得できる。法人API 口座API 振込申請API 総合振込申請API 給与賞与振込申請A

wate_wate 2021/02/10

開発
API

リンク

現地で学んだ自動化、セキュリティ、API設計のアイデアと実践～ドイツのPHPカンファレンスレポート 2日目 - ぐるなびをちょっと良くするエンジニアブログ

こんにちは！ぐるなびエンジニアの宮原です。 2016年10月末に、ドイツ・ミュンヘンで開催されたInternational PHP Conferenceに行ってきました。 1日目の様子はこちら。 International PHP Conferenceでは、お土産にPHPバッグをもらいました。ペンや小物を入れるところがたくさんついていたり、ノートPCを保護する機構が入っていたりと、エンジニアには便利そうです。それでは、2日目のセッションの紹介を始めます！今回は、自動化、セキュリティ、API設計のお話が出てきます！セッション紹介（2日目） Automating All The Things @movetodevnullさんによる「なんでも自動化しようぜ！」という発表です。以下4つの場面で使えるツールと、自動化する具体的な方法が紹介されました。 System Configuration

wate_wate 2016/12/22

リンク

翻訳: WebAPI 設計のベストプラクティス - Qiita

これは Enchant の開発者である Vinay Sahni さんが書いた記事「Best Practices for Designing a Pragmatic RESTful API」1を、ご本人の許可を得て翻訳したものです。 RESTful な WebAPI を設計しようとすると、細かなところで長考したり議論したりすると思います。また、他の API に倣ってやってはみたものの、本当にそれでいいのか、どうしてそうしているのか分からない、何てことも少なくはないと思います。この記事では、そのようなハマリどころについて Vinay さんなりの答えを提示し、簡潔かつ明快に解説してくれています。今後 WebAPI を設計される方は、是非参考にしてみてください。なお、誤訳がありましたら編集リクエストを頂けると幸いです。まえがきアプリケーションの開発が進むにつれて、その WebAPI を公

wate_wate 2016/03/26

リンク

http api design

以下なドキュメントを発見しておりまして。 HTTP API Design Guide なんとなくメモをとってみました。 Contents として以下が列挙されています。適切なステイタスコードを戻しなさい戻すことができる全てのリソースを戻しなさいリクエストボディに含まれるシリアライズされた JSON を受け付けなさい ID じゃなくて UUID 使った方が良いですよ標準的なタイムスタンプを使いましょう UTC 時刻は ISO8601 フォーマットで使いましょう一貫性のあるパスフォーマットを使いましょう小文字とダッシュを使いましょう外部キーのリレーションは入れ子に利便性をはかるため non-id dereferencing をサポートしなさいエラーの場合のレスポンスボディについて ETag ヘッダを含めなさい Request-Id ヘッダを API レスポンスに含めなさい P

wate_wate 2016/01/29

API
開発

リンク

小さなサーバーで大きなサービスをつくる | カメリオ開発者ブログ

アーキテクトのItoです。動画を撮るのが趣味ですが、最近はこの本を買って、カラーグレーディングの勉強をしています。とても良い本です。さて、今回お話するのはバックエンドにあるフロントエンドについて。以下はほぼ実際にカメリオで運用しているバックエンド構成です。図中のサーバーというものはいわゆるHTTPベースのサーバーアプリで、ここでは緑をNode.js, グレーをPython, C++で実装しています。小さいサーバーがたくさんあります。主にクライアント〜フロントエンド APIだけの構成図で、記事クローラーや各種管理画面などは図にはありませんが存在します。まずフロントエンドにELB(AWSを使用)とNginxを置き、後ろに Nodeベースのフロントエンド APIサーバーを置きます。ここはNode.jsで作られたアプリをサービスするごく一般的な方法です。エンドポイント(api.kamel.