というのをふと思いついたのでメモ程度に残しておく。あとからサンプルコードとともにちゃんと公開する それぞれの課題 フロントエンドエンジニア/デザイナーの課題 APIサーバーを叩く必要があって必要なJSONがほしい サーバーサイドの実装が待ちになると生産性が低い APIの仕様が変わる場合早く知らせてほしい Swagger ドキュメントの課題 実装とドキュメントの乖離が起きがち Swaggerには書かれてるけどまだ実装が終わっていない 実装は終わってるがSwaggerが更新漏れしていた サーバーサイドエンジニアの課題 APIの仕様が変わると実装のvalidationなどの変更が面倒 サーバーサイド実装作ってみて、フロントエンドに渡したあとで仕様変更が発覚した 課題 ドキュメントと実装の乖離は少なくしたい フロントエンドとサーバーサイド分けて実装したい gRPC + grpc-gateway h
この記事では以下の内容について記述しています。 Swaggerの基礎概念 Swagger Editorを使ったAPIのドキュメント作成 Swaggerで作成したAPIのドキュメントを元にモックサーバを立てる Swaggerとは? 公式より Swagger is the world’s largest framework of API developer tools for the OpenAPI Specification(OAS), enabling development across the entire API lifecycle, from design and documentation, to test and deployment. SwaggerはOpenAPI(OAS)のための世界最大のAPI開発フレームワークであり、APIのライフサイクル全体にわたって、設計からドキュ
こんにちは。スタートトゥデイテクノロジーズ新事業創造部のid:takanamitoです。 今日はVASILY時代から活用されているOpenAPI(Swagger)の定義からRubyのクラスを自動生成するgemを作ったので、その紹介をしようと思います。 Swaggerの定義と実際のAPIが返すレスポンスの内容がズレている 弊社ではVASILY時代からSwaggerの導入が進んでいましたが、徐々に「Swaggerの定義と実際のAPIが返すレスポンスの内容がズレている」といった問題が発生しはじめていました。 その問題を解決するために今回つくったのがこのgemです。 github.com 例えばこんなOpenAPI Specification 3.0のYAMLの定義から schemas: user: type: object properties: username: type: string u
License: CC-BY-SA 3.0 © Zalando SE 2020 & CC-BY-SA 3.0 © kawasima 2020 Zalandoのソフトウェアアーキテクチャは、疎結合なマイクロサービスを中心としており、 それらはJSONペイロードをもつRESTful API群によって、機能が提供されています。 小さなエンジニアのチームは、自分たちでAWSアカウントにこれらのマイクロサービスを デプロイしたり運用したりしています。 私たちのAPIは、その多くが私たちのシステムが何をするのかを完全に表現しており、 それゆえに貴重なビジネス資産となっています。 Zalandoがとあるオンラインショップから価値あるファッションプラットフォームへと変貌を とげるために、私たちは新しいオープンプラットフォーム戦略の展開をはじめました。 なので、高品質で長持ちするAPIの設計は、私たちにとっ
Most modern web applications are powered by a REST API under the hood. That way, developers can separate the front-end code from the back-end logic, and users can interact with the interface dynamically. In this three-part tutorial series, you’ll build a REST API with the Flask web framework. You’ll create a foundation with a basic Flask project then add endpoints and connect them to a SQLite data
API サーバーを構築する際に swagger (https://swagger.io/) を用いて仕様を定義することが増えてきているように見えますが、せっかく DSL ベースで API 仕様を表現しているのですから、その情報を用いて色々な作業を楽にしたいですよね。 この記事では Swagger とその周辺ツールを用いて出来ることの一つとして、API のテストツールとしてデファクトスタンダードに近づいてきた postman (https://www.getpostman.com/) と連携して自動 API テストを試みます。 サンプルファイル はじめに、元になるサンプルファイルがあった方が分かりやすいと思うので、以下例示します。なおファイル中に書かれている事に特に意味はないので、細かいツッコミは無用です。 { "swagger" : "2.0", "info" : { "descripti
Model Composition In your API, you may have model schemas that share common properties. Instead of describing these properties for each schema repeatedly, you can describe the schemas as a composition of the common property set and schema-specific properties. In OpenAPI version 3, you do this with the allOf keyword: components: schemas: BasicErrorModel: type: object required: - message - code prop
まえがき 社内向けのメモとして書いたら、「これQiitaに上げたらいいんちゃう?」って言われたので上げます。 ほんとにOpenAPIとかSwagger始めて触るチームで共有する用に書いたので、おかしなところがあったら教えてください。 これ書いてる自分もSwagger始めて触ります。 これ書いたときの状況はこんな感じ。 Webアプリ開発中で、チーム全員がVSCodeを使っている。 チームで使えるSwagger Editorの環境を作った直後。 タスク管理はJIRA 内部ドキュメント系はConfluenceで管理 はじめに Swagger Editorが動くサーバも立てて、「さて、swagger使うか!」とは言うものの、書いたspecはどうやって管理する? ってことを考えていろいろやったことメモ。 TL;DR specはソースと一緒にgit管理するのがいいんじゃない? ついでにvscodeのs
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く