You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
他言語からTypeScriptに変換する記事を観測したので、JSONSchemaを経由してTypeScriptのコードに吐き出すライブラリを作りました。本記事のコアロジックの部分を抽出した形です。 OpenAPI TypeScript Code Generatorとの違いとして、ルートの名前空間を廃止しているので、割と自由に書ける様になってます。 https://www.npmjs.com/package/@himenon/jsonschema2ts
このブログを公開した数日後にAWSからサーバーレス開発者ポータル提供開始の案内がありました。 ケースバイケースですが、APIのドキュメント公開についてはサーバーレス開発者ポータルの利用も有力な選択肢になりそうです。 API Gateway のポータルサイトを簡単に構築できるサーバーレスアプリを試す サーバーレス開発部@大阪の岩田です。 サーバーレス開発部の良くある案件パターンとして、Web APIのバックエンド開発やIoTを絡めた案件が挙げられます。 こういった案件では通信仕様の設計からクラメソで対応することが多いのですが、プロジェクトを円滑に進めるためには単に通信仕様を設計するだけでなく、呼び出し側のお客様や他社ベンダーとの認識合わせや仕様の調整が重要になってきます。 現在関わっている案件では、GitリポジトリへのPushをトリガーにS3にドキュメント類をアップロードし、S3の静的Web
この記事はCamphor- Advent Calendar 2019 15日目の記事です。 Squelette: Yet another TS codegen ecosystem for Open API. Embedded content: https://github.com/andoshin11/squelette 本Advent Calendarへの参加も今年で4回を数えます。フロントエンドなAndyです。 ここ数年の間に加速度的にTypeScriptの利用機会が増え、Webブラウザで動くSingle Page Applicationの世界にも静的型付けの考え方が浸透してきました。 Redux, VuexのようなRepositoryレイヤーからUIコンポーネント内のビジネスロジック、ひいてはDOMにいたるまで一気通貫に型の恩恵を感じることのできる開発体験は、今後もしばらくメイントレ
The panel below displays documentation all endpoints, parameters and error messages available to the Marvel API. For a more detailed explanation of API structure, please read the full documentation. If you have an API key, you can also test API calls directly from this panel. Just log-in to your Marvel account and your key will be pre-filled. (If you don't have a key, get one now.) You do not have
Rails での JSON API 実装まとめ 前後リンク RESTful API のおさらい Rails での JSON API 実装まとめ スキーマファースト開発 The NEXT of REST Ruby on JSON の図のような流れになるんですが、それぞれ見ていきます。 to_json (2011-2013 頃) 2011-2013 年頃、僕らは render :json を使っていました。 render json: @user render json: @user.to_json として User#as_json や User#to_json を利用します。 この頃はまだ SPA という言葉もなく、ネイティブアプリもそこまで流行っていなかったので これで十分だったのですが、どんどん API に世の中が寄っていき、限界を迎えます。 この頃のツラみ JSON を組み立てるのが大変
第 2 部 で 現在 5 派閥ぐらいありそうです。 と書いた中でなぜ OpenAPI を選んだのかというと、 JSON Hyper-Schema は Hypermedia の技術なので、1 サーバ 1 クライアント、同一チームで両方を見るという private API では出番が無い。 RAML はコミュニティ規模が OpenAPI, API Blueprint に比べて小さかった OpenAPI と API Blueprint、生 JSON Schema だと、OpenAPI が一番「RESTful API」に特化していて、かつ詳細度が高い といった辺りです。 OpenAPI は ruby だとライブラリが (当時は) 少なかったのですが、まぁ作れば何とかなるだろうと採用しました。 最近のトレンドでも Swagger 1 強になってるっぽくて、良い選択をしたなぁと思っています。 Open
SwaggerやOpen API Specification（以下OAS）はAPIのデファクトフォーマットになってきています。特にこれらのフォーマットでドキュメントを作っておくと、関連するライブラリやドキュメントが自動生成できるのが便利です。 Swagger/OASを使ったモックサーバであったり、テスト環境やエディタなどをまとめて提供してくれるのがSwaggerHubです。Swagger周辺のエコシステムを活用したい方はぜひ使ってみてください。 SwaggerHubについて SwaggerHubはSwagger/OASファイルの編集とプレビュー、ドキュメント表示などに加えてモックサーバを立ち上げたり関連するサーバ、クライアント双方のライブラリが生成できます。 設定は公開することもできるので、そのままAPIドキュメントとして開発者に使ってもらうことができます。 仕組みとしてはGitHub風で
Documentation Driven Contractsについて調べてみた May 15, 2017 ( May 15, 2017 更新 ) モチベーション 最近業務で、社内の他のチームに提供するAPIを開発している。 関わっている人が少なければ、みんなで近くに座って都度仕様について相談していけばいい。（感覚的には〜7人くらい？） しかし、会社全体の人数が多く、関わるチームも複数いるため（サービスのモバイルアプリ担当、Webフロント担当、バックエンド担当…など）包括的で都度更新されるドキュメントがないと開発効率が悪い。 とはいえ、API提供チームとしては、実装になるべく多くの時間を使いたい。具体的には以下の条件を満たす手法があればよい: ドキュメント作成にかける時間を短くできる 作成したドキュメントの内容が正確（最新であることが必須） 一番原始的な手法として、ドキュメントをちまちま人手
The Swagger framework changed the software landscape forever, allowing APIs to be described in a common language (the OpenAPI Specification) that every human and machine involved in the lifecycle can understand, work and integrate with. While the specification is the core of the framework, there is an entire toolchain around it to enhance the API development process. The most popular and fundament
Today I released version 0.12 of the JAX-RS Analyzer. As main improvement JavaDoc of JAX-RS resources will now taken into account for Swagger JSON. <plugin> <groupId>com.sebastian-daschner</groupId> <artifactId>jaxrs-analyzer-maven-plugin</artifactId> <version>0.12</version> <executions> <execution> <goals> <goal>analyze-jaxrs</goal> </goals> <configuration> <backend>swagger</backend> </configurat
背景 最近は変化し続ける要件に対応するために、システムも柔軟であることが求められています。 そのため、部分的に変更やスケールの可能なシステムを構築し、API経由で連携するマイクロサービス的アーキテクチャが増えてきています。 そういった設計の中で問題になっていくのが、従来のモノリシックなアプリケーションではIDEやコンパイラなどで行っていた、機能間のインターフェイスをどう管理するかという部分です。 Swaggerとは? SwaggerとはRESTful APIのドキュメントや、サーバ、クライアントコード、エディタ、またそれらを扱うための仕様などを提供するフレームワークです。 公式サイトでは、The World's Most Popular Framework for APIsと謳っています。 その理由は、マイクロソフト、Google、IBM、SmartBearなどを大手の企業を含む「Open
2016 - 09 - 28 KotlinとSpring Bootとか諸々を使ってMicroservicesを作ってみた 最近バックグラウンドで稼働する決済系のMicroservicesをKotlinで作ってめでたく運用開始したので、どんな感じでやったかを雑に共有。 Kotlin選択の理由 自分は Scala が好きなんですけど、周りに書ける人いないし、そんなに時間もないし、で素の Java もダルいしってなって現実的な解となったのがKotlinだったに過ぎません。 kotlinlang.org Java をバックグラウンドに持つ人が多い今のプロジェクトではなかなかよかった気がしてます。 コンパイル 速度もほどんど気にならなかったし満足（規模が大きくなったらどうなるだろうかというのはあるが）。 spring-boot-starter-web 手堅くSpring Bootを利用。もちろんKo
REST APIを記述せよ！APIのライフサイクルを支える新標準OpenAPI モバイルアプリの爆発的な普及をきっかけに、サービスバックエンドの Web API 化が急速に進んでいます。この動きは単なる内部実装に留まらず、企業がビジネスを API 化してネット上に展開する、という大きな流れを生み出しています。 API Meetup は、Web API に携わる開発・企画担当者が、API まわりの様々な要素技術や適用事例を一緒に学ぶオープンミートアップです。 今回は、昨年11月に結成されたOpen API Initiative (OAI)により標準化が進められているREST APIの記述フレームワーク、OpenAPI Specification（旧称Swagger）を特集します。チュートリアルから実践経験談、OAIメンバ企業によるLTまで、OpenAPIの「いま」がわかるイベントです！ セッ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
