「API仕様ファースト開発」という用語は、私自身が雑誌「WEB+DB PRESS Vol.134」の特集1「実践API設計」を執筆する際に考えた造語です。 全く新規にサービスを開発する場合の開発順序は次のようになります（記事の題3章の図1）。 これは、私自身が初めてメルペイで担当して、一からマイクロサービスを開発したときの開発順序です。そして、その後、チーム移動により別のマイクロサービスの開発へ移動したり、カウシェへ転職したりした際に、最初に導入したのはE2Eテストフレームワーク（記事の第4章「E2Eテストフレームワークの構築」）でした。 そして、API仕様の技術的負債（エンドポイントの仕様が書かれていなくて、それをテストするE2Eテストもない状態）を返済するために、次の開発順序（記事の第5章の図1）を自分自身も行い、他の開発者達にも行ってもらうようになりました。 この開発プロセスが定着す
一行要約 はじめに Readable OpenAPIとは? 既存ルールの不満点 不満点1: 標準仕様外の分割を行っている 不満点2: ディレクトリ階層が深い 不満点3: 1つのAPI定義を参照する際にたくさんのファイルを参照する必要がある 不満点4: コンポーネントスキーマの同一性が不明瞭 新ルールで工夫した点 工夫1: operationIdと対応したパス定義のファイル名を採用し、フラットなディレクトリ構造を実現した 工夫2: パス定義ファイルに含まれる情報量を増やした 工夫3: 再利用性を重視したcomponent定義 できなかったこと、やらなかったこと、やりたいこと 定義ファイルのhttpメソッドごとの分割ができなかった ルートの定義ファイルにcomponentディレクティブを置かなかった exampleの定義は余力があればやりたい おわりに We are hiring! 脚注 一行
これは NTT Communications Advent Calendar 2021 3日目の記事です。 こんにちは、イノベーションセンターの松田 (@take4mats) です。 当社の Smart Data Platform (SDPF) のサービスラインナップの多くは、お客さまがサービスご利用に必要な操作を統一的に行うための Web UI に加え、同等の Web API を提供しています。 API 仕様は Knowledge Center にてサービスごとに一般公開されているのをご存知でしょうか？ (Knowledge Center で各サービス内の APIリファレンス のページをご覧ください。例えば こちらのリンク) この一般公開されている API 仕様はサービス開発初期に作成され、開発期間にも重要な役割を果たしています。 本記事では、その中で私が携わったサービスから、 API
皆さん、こんにちは。 とらのあなラボのおっくんです。 「バーコードを見れば、なんとなくは読める」となんてことを言う友人がいます。 詳しく聞くと、すべてではないけれど一次元バーコードであれば目で見てなんとなく読めるんだそうです。 言うからには「読めると何かしら便利なんだろうな」と感じたので、技術に頼ってバーコードを読んでみることにしました。 使用する「Shape Detection API」と作成したアプリを紹介します。 最終的に完成したのがこちらです。 順を追って解説します。 実行環境 開発環境 OS:macOS Catalina 10.15.4 Chrome 84.0.4147.89 確認用デバイス OS:Android バージョン 10 Chrome 83.0.4103.106 Shape Detection API とは Shape Detection API は、外部のライブラリに
概要 今回は、OpenAPI Specification(以下OAS)駆動でREST API開発をすることで享受できる恩恵と制限についてお伝えできればと思っています。 序文 MF KESSAI(以下MFK)で、Backend開発を行っているusumachi(a.k.a usuimachinami)と申します。 開発に対し “気合ブリバリ” でそれはもう横須賀最強 麓沙亜鵺です。 さて、MFKでは導入企業様のさらなる請求業務の効率化を目指し、REST APIを提供しています。 開発に際してインターフェースの仕様定義のために、OASを利用して開発を行っています。 また、最近のMFKは試作（prototyping）を繰り返してより良いものを作ろうという動きがあります。 この方針とOASを利用した開発がとても適合しました。 OpenAPIとは OASとは正式名称でOpen API Specific
安全で、誰にも手頃でアクセスしやすく、ユーザーを尊重したWebを作るためのHTTPヘッダーのプラクティス [UI/UX]原文 HTTP headers for the responsible developer - Twilio (English) 原文著者 Stefan Judis 原文公開日 2019-04-23 翻訳依頼者 翻訳者 meiq 翻訳レビュアー doublemarket msh5 原著者への翻訳報告 1950日前 メールで報告済み 編集 This article was originally published on twilio.com, and translated with the permission of Twilio and the author. 当記事の原文はtwilio.comにて公開されたものであり、Twilio社および原著者の許可を得て翻訳しています
デフォルトでは半角スペースはパスワードに含まれないようになっています。 デフォルトのパスワード生成 $ aws secretsmanager get-random-password { "RandomPassword": "h}';Ih+J46RLy&:{zH]0sHw7lU;}f<.>" } パスワードの長さはデフォルトで32文字です。 タイプ一覧の表の通り 小文字/大文字アルファベット 数字 句読点 から構成される 32 文字のパスワードが生成されます。 パスワードの長さを制御 パスワードの長さを変更したい場合、PasswordLength オプションを渡します。 $ aws secretsmanager get-random-password \ --password-length 10 { "RandomPassword": "X)/G#4;kh|" } デフォルトは 32 で、1
東京公共交通オープンデータチャレンジについて 公共交通オープンデータ協議会は、世界一複雑とも言われる東京の公共交通を、誰もがスムーズに乗りこなせるようにすることを目指し、「東京公共交通オープンデータチャレンジ」と題して、公共交通オープンデータを用いたアプリケーションを募集するコンテストを開催してまいりました。 本コンテストは、2017年の第1回を皮切りに、多数の交通事業者等の協力のもと、約4年に渡り継続的に実施しました。本協議会会員のJR東日本、東京メトロ、東京都交通局を含む、主要な公共交通事業者のデータを利活用できる、これまでにない規模のコンテストとして実施され、多数の方々のご参加、及び、バラエティ豊かな数々の作品のご応募をいただきました。個人の開発者から乗換案内サービス事業者にいたるまで、国内外の多数の参加者にデータを活用いただき、社会的にも大きな成果を挙げることができました。チャレン
はじめに iOSアプリ開発をしていて役立つWebサービスやツールがありますので備忘録としてまとめてみました。アプリ開発を始めるところからリリース後までを順番に書き並べています。ぜひiOSアプリ開発をしている方は参考にしてください。（Androidアプリ開発している方にも使えるものはあると思います。） UI/UXを考える プロトタイプを作成する アプリを作る前にデザインをまず決めますよね。その際に、実際にスマホで閲覧したときにどのように見えるのか、どのようなインタラクションにするかを議論します。そんなときに便利なプロトタイプ作成サービスがあるので、いくつか載せておきます。 サービス URL Justinmind http://www.justinmind.com/ Flint for Mac https://www.flinto.com/mac POP https://popapp.in/
iOS Advent Calendarの13日目を担当します@giginetです。 APIクライアントを作りたいなあと言う気概になったので、APIクライアントをライブラリ化するまでの方法をご紹介します。 なお、この記事は執筆時点の最新の環境で検証しています。 Xcode7.2 Swift 2.1.1 Carthage 0.11.0 今回使用するAPI 今回は、APIクライアントが見当たらなかったので、WakaTimeという、エディタからデータを送り、自分のプログラミングについてのデータを集積してくれるサービスのAPIクライアントを作って、自分の1週間のコーディングを管理できるようにしてみました。 完全自動で、自分のプログラミング「作業ログ」を収集して可視化する「WakaTime」が素晴らしい件！ | シェアしたくなる最新のWebサービス・ITニュース情報をチェック！ APPGIGA!!（ア
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon | A Philosophy of Software Design | John Ousterhout | Programming
