Zalando RESTful API と イベントスキーマのガイドライン
License: CC-BY-SA 3.0 © Zalando SE 2020 & CC-BY-SA 3.0 © kawasima 2020 Zalandoのソフトウェアアーキテクチャは、疎結合なマイクロサービスを中心としており、 それらはJSONペイロードをもつRESTful API群によって、機能が提供されています。 小さなエンジニアのチームは、自分たちでAWSアカウントにこれらのマイクロサービスを デプロイしたり運用したりしています。 私たちのAPIは、その多くが私たちのシステムが何をするのかを完全に表現しており、 それゆえに貴重なビジネス資産となっています。 Zalandoがとあるオンラインショップから価値あるファッションプラットフォームへと変貌を とげるために、私たちは新しいオープンプラットフォーム戦略の展開をはじめました。 なので、高品質で長持ちするAPIの設計は、私たちにとっ
Zalando RESTful API and Event Scheme Guidelines
Zalando’s software architecture centers around decoupled microservices that provide functionality via RESTful APIs with a JSON payload. Small engineering teams own, deploy and operate these microservices in their AWS (team) accounts. Our APIs express most purely what our systems do, and are therefore highly valuable business assets. Designing high-quality, long-lasting APIs has become even more cr
Web API 設計のベスト プラクティス - Azure Architecture Center
ほとんどの最新の Web アプリケーションでは、クライアントがアプリケーションと対話する際に使用できる API を公開しています。 適切に設計された Web API には、次をサポートする目的があります。 プラットフォームの独立。 API の内部的な実装方法に関係なく、すべてのクライアントが API を呼び出すことができる必要があります。 そのためには、標準プロトコルを使用し、クライアントと Web サービスが交換するデータの形式に同意できるメカニズムを備えている必要があります。 サービスの進化。 Web API はクライアント アプリケーションから独立して進化し、機能を追加できる必要があります。 API の進化に伴い、既存のクライアント アプリケーションが変更なしに引き続き機能する必要があります。 クライアント アプリケーションが機能を十分に使用できるように、すべての機能が検出可能である
OpenAPIはいいぞ - Qiita
この記事は Open API Advent Calendar 2017 の 1 日目の記事です。 Open API Specification は、 Open API Initiative が策定を進めている REST API を定義するための仕様です。どの URL にどのようなパラメータを渡すとどのような結果が返ってくるかを記述するための JSON/YAML ベースのフォーマットで、ツールやサービスとの連携も図られています。 今年 2017 年は、 3.0.0 がリリースされました。元となった Swagger が 1, 2 で Open API Spec としては最初のバージョンとなります。 構造の改善 が入り、全体的に使い勝手が良くなった・細かいハックをしなくても運用しやすくなったという印象です。 また、 2016年の API Blueprint (apiary) に続き RAML の
JSON APIのJSONデザイン | LastaFlute
LastaFluteのドキュメントではありますが、どんなフレームワークを使っていても JSON API を構築するときに通じるお話かもしれません。 一方で、jfluteもまだまだ研究中のテーマなので、何か要因が見つかれば随時更新していきます。 概要 まず、これを決めましょう どちらかと言うと、特定クライアント向けAPI 最初のAPIのデザインが会社標準デザイン A. そもそもJSONをどんなニュアンスで戻す？ 元データ方式？表示データ方式？ 様々な判断の基本コンセプトに どちらかと言えば元データ方式推奨？ B. エラー表現 (Failure統一？共通ヘッダー？) Failure統一パターンとは？ 共通ヘッダーパターンとは？ Failure統一パターンのメリット 共通ヘッダーパターンのメリット Failure統一？共通ヘッダー？ or ... C. JSONのデータ型 型付き？型なし？ 型付
RAML 1.0リリースと最新のMuleSoftのAPIニュースに関するUri Sarid氏へのインタビュー
InfoQはサンフランシスコで開催されたMuleSoftのCONNECT 2016のカンファレンスにおいて、CTOであるUri Sarid氏と話す機会を得た。Sarid氏は待望の正式公開版であるバージョン1.0がリリースされたばかりのRAMLの考案者であり、昨年のインタビューの続報や、APIチームのためのMuleSoftのソリューションの関する俯瞰的な観点、APIに対する彼のビジョンを聞く良い機会である。 InfoQ: あなたのMuleSoftにおける役割と、業務の中でAPIとどう関わっているかを教えてください。 Uri Sarid氏: 私の役割はCTOであり、弊社のプラットフォームのアーキテクチャに加え、プラットフォームのビジョンや方向性についても同様に責任を持っています。APIは私たちがやっている全ての物事のフロントと中心に位置しています。これらは私たちのアプローチの中心を成すものであ
HATEOASって何だ? - uehaj's blog
Grails 2.3のRest機能のドキュメントを読んでいたら、拡張の一つとして「8.1.7 Hypermedia as the Engine of Application State」というのが書いてあって、調べると面白かったので、この資料(REST: From GET to HATEOAS)を読んだだけでの、私の理解する限りのメモを記しておきます。 一言でいうと、HATEOASとは、Restfulパターンを拡張するアーキテクチャパターンで、Restful原則に対する追加的な制約。どういうものかというと、HTMLアプリの画面遷移を抽象化した、状態遷移を表現するRestful API(=Restful WebアプリのWebインターフェース)を設計するための具体的な方法論になってる。 もちろんGrailsに特化したものではなく、Restと同じレベルのWebアプリケーション一般概念でありRes
Tony Tam氏に聞く- Open API InitiativeとSwaggerの最新情報
11月の初め，Linux Foundationが発表したOAI(Open API Initiative)にあげられた華やかな創設メンバ一覧を見たAPI開発者たちは，標準に関するコンセンサスを推進するというOAIの役割に疑問を持たざるを得なかった。 Swaggerプロジェクトの創設者であるTony Tam氏は，11月末にテキサス州オースチンで開催されたAPI Strategy and Practice Conferenceで，このような疑問の中のいくつかを取り上げた。読者も関心を持つであろうこれらの疑問について，より詳しい回答を得るべく，InfoQはカンファレンスに氏を訪ねた。 InfoQ: SmartBearにおけるあなたの新たな役割と，参加を決めた理由について教えて頂けますか？ Tony Tam: 私がSmartBearに加わったのは，Swaggerの開発をフルタイムで行なうことのできる
RESTful APIの記述標準化を目指す「Open API Initiative」をマイクロソフト、Google、IBMらが立ち上げ。Swaggerをベースに
RESTful APIの記述標準化を目指す「Open API Initiative」をマイクロソフト、Google、IBMらが立ち上げ。Swaggerをベースに 10年以上前、XMLの登場に続いてXMLベースのAPIを記述する標準フォーマット「WSDL」が提唱されました。 WSDLにはAPIの仕様がマシンリーダブルな形で記述されており、APIを呼び出すためのプロトコルやデータフォーマットをあらかじめ知ることができます。WSDLを利用することで、APIをコールするためのコードを自動生成することが可能でした。 しかしXMLベースのAPIは期待されたほど普及せず、現在ではよりシンプルなRESTful APIが事実上の標準となっています。 そしてRESTful APIのためのWSDLとも言うべき、RESTful APIのインターフェイスを記述するための標準フォーマットを推進する団体「Open AP
Design Driven API Development
This document discusses design-driven API development using API description languages like Swagger and RAML. It recommends generating documentation and code from a single API schema to avoid inconsistencies. This approach allows server code and related resources like SDKs and tests to be generated from the schema rather than developed separately. The document provides an example using Swagger-Node
RESTful#とは勉強会で(Railsでの)ルーティングの考えだし方の話をしました - moroのブログ
RESTful な設計って、ってマスタメンテ作るにはいいけどまともなサービス作れるの? という疑問に対して、結構やればアプリケーションできるので安心してください、という話をしました。 「独自研究」セクション以外はだいたいふつうに経験したことです。「独自研究」セクションはたぶん、今流行りのオーケストレイションレイヤをどうするかというところになるのかな、と。APIといいつつ、HTMLを返す話ばかりですが、これはAPIとHTMLをあえて区別せずそれは単にリプレゼンテーションが違うだけです、という意図でした。 転職してから初の社外発表が前職オフィスでやるというのが面白かったです。永和メンバーも結構たくさん会えてよかった。来てくださった方、開催をアレンジしてくださった方、ありがとうございました。
WebAPIでエラーをどう表現すべき？15のサービスを調査してみた - Qiita
2017-01-05 追記 2016年3月にエラーの標準形式RFC7807「Problem Details for HTTP APIs」が提案され、今日現在proposed standard(標準化への提唱)となっています。こちらも是非ご覧ください。 RFC 7807 - Problem Details for HTTP APIs HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様 最近はREST APIを提供しているサービスが増えてきていますね！また公開されるAPIだけでなく、Microservicesなアーキテクチャを採用して、バックエンドがWeb APIで通信するケースも増えてきているように思います。 APIを使うときはあまり気にしたこともなかったですが、いざAPIを設計してみるとどんなインターフェイスがいいのか、どんな形式がいいのかといった疑問が次々と出てきます。
Rubyist Magazine - スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編)
『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0063 号 バックナンバー Rubyist Magazine 0063 号 Rubyist Magazine 0062 号 Kaigi on Rails 特集号 RubyKaigi Takeout 2020 特集号 Rubyist Magazine 0061 号 Rubyist Magazine 0060 号 RubyKaigi 2019 直前特集号 Rubyist Magazine 0059 号 Rubyist
[Apiary]Markdownで始めるAPI開発とAPIドキュメント作成 | DevelopersIO
APIを作るとき みなさん、毎日API使ってますか？私は、ワンライナーでAPIをコールすることにハマっています。さて、いつも使っているAPIを作る側になったとき、どのように設計していますでしょうか？また、作ったAPIをどのように使ってもらっていますか？そんな疑問に応えるサービスがApiaryです。 Apiaryとは？ Apiaryは、REST APIをサクッと書けるサービスです。また、APIドキュメントも生成してくれます。モックサーバも提供してくれます。API利用サンプルコードも作ってくれます。うん、使わないって選択肢は無いですねｗ。 無料登録すると早速使えるようになります。チームでプライベートなAPI開発をしたければ有料プランを選択してください。 API開発の流れ API開発の流れは、まずはじめにMarkdown形式でドキュメントを書きます。既にサンプルがあるのでこれを使ってみましょう。
![[Apiary]Markdownで始めるAPI開発とAPIドキュメント作成 | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/60d7120d91185f1739fec5fcbd006f066b98e9f6/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2015%2F02%2Fapiary-logo.png){kind=logo}
RESTのベストプラクティス | POSTD
現在ではREST APIはとても一般的な話題です。ほとんどすべてのWebアプリケーションの一部分となっています。シンプルで一貫性があり実際的なインターフェースは必須です。これは皆さんのAPIを他の人が使うことをとても容易にします。皆さんにとってはRESTの実践が日常的に感じられるかもしれませんが、RESTをあまり尊重しない人々もよく見かけます。これがRESTについて投稿するきっかけでした。 この記事にはRESTfulなAPIを設計する時に考慮すべきベストプラクティスがあります。 注意 : ここでのベストプラクティスは、私が過去の経験に基づいて良いと考える事例です。もし違う考えをお持ちであれば、お気軽にメールをくだされば意見交換できると思います。 APIのバージョンを示す APIのバージョンは必須であるべきです。これがあると時間が経ってAPIが変わっても影響を受けません。その方法の1つはUR
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
api-guidelines/Guidelines.md at master · microsoft/api-guidelines
よりよいAPIを作るために
MuleSoft、RAML 1.0とAPI Workbenchを発表
RESTful considered harmful
apidoc.me