HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様
今日では HTTP(s) で API が公開されることは当たり前の時代ですが、エラーをアプリケーションにどう伝えるかは、個々の API の設計に依存していました。特に、HTTP ステータスコードは有限であり、元々持っている意味があるので、自由に使うことはできません。API はそのドメインごとにもっと複雑で細かなエラー情報があるはずで、それらはレスポンスボディに載せてアプリケーションに伝えることになりますが、その書式に規定は今までありませんでした。 HTTP API にて、アプリケーションにエラー情報を伝達するための（レスポンスボディに載せられる）標準的な形式が、RFC7807 Problem Details for HTTP APIs で定められています。適用例としては、以下のようになります。 HTTP/1.1 403 Forbidden Content-Type: application
Pythonで作ったデーモンにREST APIをつける話 - Qiita
目的 Pythonで24時間走らせ続けるデーモンを書いています。稼働状況の確認や設定を動的に変更をするためにREST APIを追加することにしました。メインルーチンに大きな変更を加えることなく、最小の手間で実装する方法を模索しました。 FlaskとFlask-API REST APIを提供するにはなんらかのウェブサーバが必要です。外部に公開するものではないのでFlaskが同梱している開発用のウェブサーバを使います。開発用ですがスレッドで同時アクセスにも対応していますので、十分実用に耐えます。 REST APIは手軽に実装できてテスト用のUIまで用意されているFlask-APIを使うことにしました。 以下の実験ではFlask-APIのサンプルを使います。コピペしてexample.pyというファイルで保存します。 http://www.flaskapi.org/#example マルチスレッド
Rubyの会社のフロントエンドエンジニアが、GolangでAPIサーバーを開発してみる。 - Qiita
初めまして。マネーフォワードでフロントエンドエンジニアをしている高山です。 Money Forward Advent Calendar 2016と言う事なんですが、 Advent Calendarを書くのが今回初めてでもあり、Qiitaに投稿するのも初めてだったりします。 「え。なに、アウトプットしてないの」と、思われがちですが、Web帳と言う意識の低いゆるいブログをかれこれ6年程書いております。 気になった事とか、メモ程度に不定期に書いていたりします。 また、それとは別に、今年の頭くらいに 新たなCSS Architecture として、APBCSSを提唱させていただきました。 CSS Architectureが、「お。良いなぁ。」と思った方は是非導入して頂ければ幸いです。 と言う訳で、自己紹介はそのぐらいで、今回はタイトルである通り、CSSでもなく、JavaScriptでもなく、Rub
GoでAPIサーバーの開発からデプロイまで - Qiita
はじめに この記事はGo Advent Calendar 2016 の14日目の記事です。 最近Ergodoxを購入したGopherです。 今年の3月からGoを使用してサービスの開発をしています。 Goを使用したのは初めてで、色々と調べながら開発環境の作り方、開発からデプロイまで一通りやってきたので、まとめて書き出したいと思います。 作ったもの REST APIを作りました。フロントエンドはriot.jsを使用したSPAで、そのアプリケーションから呼び出されています。 サーバー構成 環境はAWSです。前段にELBを置き、GoのアプリケーションはEC2上で動作します。EC2はAuto Scalingグループに属し、CodeDeployによりアプリケーションがデプロイされます。Auto ScalingとCodeDeployの連携が絶妙で、スケールアウト時にはCodeDeployが最新のアプリケ
REST APIの設計で消耗している感じたときのgRPC入門 - Qiita
REST APIによる設計 最近のシステムは様々なデバイスやスケーラビリティを重視するため、各システムを分割し軽量なAPIで連携するマイクロサービス的なアーキテクチャスタイルが増えてきています。 そして、そのAPI連携で広く採用されているのが、REST APIです。 しかし、こうした設計を行っていくには、適切に考慮、選択しなければならないことも多くあります。 URL、パラメータ、エラーなどの設計 各言語ごとのライブラリや、サーバ、クライアントの選定、設計 認証、認可 ドキュメント管理 ユニットテスト、インテグレーションテスト、モック、Consumer-Driven Contracts 開発用ツール 絶対的スタンダードがない状況下で、こういった問題はシステムやメンバーが増えるにつれ複雑化していき、設計や管理、その仕組み作りに時間を取られ、本来の目的となるべき機能開発の時間を失っていくことにな
APIファースト開発勉強会に参加してきた - Qiita
11/5に @kantomi さん主催の勉強会に参加してきたので, 得られた知見などをメモしておきます. 個人的にはたいへん有意義な勉強会でありがとうございました. 機会があればまた参加したいと思います. 概要 UI, APIから設計開発をスタートする"APIファースト開発"によってDB設計の確定を後回しにし, DB設計変更による手戻り(=炎上)を防ごう. ビジネスロジックはSQLで書こう. RDBMSはいろんなことを考慮して実行計画を考えてくれる. O/Rマッパー逝ってよし. SQLで書けるかどうかはまずExcelで書いてみて考えよう. ExcelでできればSQLでできる. APIファースト開発のメリット プロジェクトが炎上してデスマに陥るのは, ひとえに"DB設計"に手戻りが発生するからである. 逆にUIとかの変更であれば, デザイナは大変だが炎上・デスマにはならない. DB設計が変更
RestfulApiの設計書 - Qiita
{ "message" : "Validation failed", "errors" : { "identify" : [ "The identify is invalid format", "The identify is too long", ], "password" : [ "The password is required", ], } } 3.柔軟性 httpパラメータで取得するパラメーターの制限、絞り込み、並び順を指定可能にしよう。カンマ区切りで複数条件可能！ * fields : 取得したいパラメーター * getNumber : ページ数 * pageSize : 1ページの件数 * sort : 並び替え * q : 文字列の部分検索 例：/companies/:companyId?fields=data&q=サンプル&sort=id,name 注釈：頻繁に使用する条
綺麗なAPI速習会 - Qiita
Wantedly Engineer blogに本速習会資料を閲覧向けに再編しました！ ぜひご覧いただけると幸いです！ 本記事は、綺麗なAPI速習会@Wantedlyの資料として作成されたものです。 同時にこちらのコードも参照してください。 マイクロサービス 流行りのマイクロサービス、何がいいのか 各々自由な言語やArchitectureでサービスを立てられる 障害の影響が部分的 変化に強い 個別デプロイ etc... マイクロサービス化をすすめるにあたり、やりとりは全てAPIで行う 内部のAPIであっても外部に公開できるようなクオリティのAPIを作成し、それを元にサービスを作っていくことが重要 APIGatewayとBFF API Gateway Pattern 公式サイトより 「見た目はモノリシック、実装はマイクロサービス」 一箇所見に行けば全てのAPIを見つけられる 細かい権限管理も可
Swaggerで始めるモデルファーストなAPI開発
This document summarizes a microservices meetup hosted by @mosa_siru. Key points include: 1. @mosa_siru is an engineer at DeNA and CTO of Gunosy. 2. The meetup covered Gunosy's architecture with over 45 GitHub repositories, 30 stacks, 10 Go APIs, and 10 Python batch processes using AWS services like Kinesis, Lambda, SQS and API Gateway. 3. Challenges discussed were managing 30 microservices, ensur
swaggerでAPIドキュメントを書いたらめっちゃはかどった話 - kaz29
Swaggerは、REST APIの仕様とそれに関連するツール群の総称です。REST APIの仕様を定義したJSONファイル(Swagger Spec)を軸に以下のようなツールから構成されています。 Swagger UI - Swagger Spec から動的にAPIドキュメントを生成するツール Swagger Editor - Swagger Specのエディタ Swagger Codegen - Swagger Specからクライアントのコードを生成するツール 最近では、Open API InitiativeがAPIの記述のためにSwaggerを採用して話題になりました。 www.publickey1.jp APIドキュメントのメンテは結構面倒 一般的にAPIの仕様書は、古くはExcel/Wordなどを使ったり、最近ではWikiやMarkdown形式で記述したりなどプロジェクトによって
API Documentation & Design Tools for Teams | Swagger
Swagger places API specifications such as OpenAPI, AsyncAPI, and JSON Schema at the core of its architecture, which are crucial for guiding teams through the entire lifecycle of API design and documentation. This strategic focus ensures that our suite, including open source tools and SwaggerHub, delivers unparalleled efficiency and a seamless user experience. Explore the API Specifications Discove
面倒な手続き不要！「Web API」の超お手軽活用術をJavaScriptコード付きで一挙大公開！ - paiza times
どうも、まさとらん（@0310lan）です。 今回は、面倒な登録手続きやトークンなどが一切不要で、今すぐ利用できる便利な「Web API」を厳選してご紹介しようと思います。 これらのAPIを使うことで、Web制作がちょっと便利になったり、独自性のあるユニークなサービスを構築できるようになるでしょう。 また、簡単に扱えることから、「Web APIを使って何か作ってみたい…」と思っている初心者の方にもオススメですよ！ ■「Web API」の使い方！ 今回ご紹介する「API」は、いずれも「JSONP」形式でデータが取得できるので、普通のJavaScriptだけで試すことが出来ます。 以下のコードを、HTMLファイルに記述するか、新規にJSファイルを作って読み込むようにしましょう。 var script = document.createElement('script'); script.src
Rails5 apiモード + JSONAPI ResourcesでAPIサーバを作る - Smoky God Express
jsonapi-resourcesはこちら cerebris/jsonapi-resources: A resource-focused Rails library for developing JSON API compliant servers. 下準備 インストールまで いつものなのでサクサクいきます。 $ bundle init # Gemfile source 'https://rubygems.org' gem 'rails', '5.0.0.rc1' $ bundle install $ bundle exec rails new . --api # 上書きを確認されるので適当にYesしておく # Gemfile # 以下を追記。 # rubygemsにあるのだとRails5に対応していないのでgithubから取得していることに注意。 gem 'jsonapi-resourc
Web API The Good PartsはWeb API開発必携の書籍でした。 #apijp - うさぎ組
はじめに これはWeb API Advent Calendar 2014の二日目の記事です。 明日はid:nobusueさんです。 概要 これはWeb API The Good Partsという書籍の感想です。Web API開発に関わる人なら必ず読んでおいたほうがいいでしょう。ここ3年くらい「URI設計はどうすべきなのか」「APIバージョンはどうすべきなのか」「続きのデータをどのように取得すべきなのか」などについて綺麗にまとまっています。 最後にWEB API開発やレビューで使いたいチェックリストがあるのも素晴らしいです。 Web API: The Good Parts 作者: 水野貴明出版社/メーカー: オライリージャパン発売日: 2014/11/21メディア: 大型本この商品を含むブログ (1件) を見る 全体 本書はWeb APIの設計、実装、レビュー、運用について細かく書かれていま
Guzzle Promiseを使った
非同期処理によるAPIコールの高速化
JavaScript で非同期処理を実現する Promise という機構はご存知でしょうか？ 今回は「Promise の考え方を PHP で実装した Guzzle Promise」を使って、大量の API コールを高速化したときの経験についてお話してみたいと思います。 Talked: - …
C++のためのAPIデザイン 読書メモ 第2章 その1 - Qiita
優れたAPIの特徴 結論からいうと, 内部実装が隠蔽されていて, 使い方がわかりやすく, 疎結合であること 問題が抽象化されていること APIは解決すべき問題の抽象概念を提供すべき. ハイレベルな概念に基づいてデザインが決定されるべきであり, 内部実装の課題を開示すべきではない. ここでいう抽象化された問題とは, 「名前と住所を管理する」といったことであり, APIで提供されるクラスと関数はその問題を解くためにあるということが表現されているべきであるということ. Personオブジェクトのリストで管理するなどという内部実装の内容はクライアントには知られてはならない. 実装の隠蔽 本書で繰り返し語られる超重要なテーマ. 実装が隠蔽されることによって, クライアントは内部実装に依存したコードを書けなくなり, 後でクライアントコードに影響を与えずにAPIの実装を変更できるようになる. クライアン
C++のためのAPIデザイン 読書メモ 第2章 その3 - Qiita
優れたAPIの特徴(再掲) 内部実装が隠蔽されていて, 使い方がわかりやすく, 疎結合であること 疎結合 優れたAPIは結合度が低く凝集度が高い. コンポーネント間の結合を可能な限り低く保とう. 疎結合であるとは, クラスのメソッドの数, メソッドあたりの引数が少なければ, それを呼び出すコンポーネントとの結合度は低い. メソッド内部でグローバル変数を書き換えるのは, 結合度が上がる. クラスの継承は, クラスの合成(コンポジション)よりも結合度が高い. サブクラスがベースクラスのprotectedメンバにアクセスできるから. メソッドのシグネチャを変えた時に, このメソッドに依存するすべてのコードの変更が局所的に行えるならば, 結合度は低い. 名前だけの結合 可能な限り前方宣言を使おう. ヘッダで別のヘッダをインクルードすると, 依存性が伝搬していく. 良くない例: #include "
OAuth 2.0 + OpenID Connect のフルスクラッチ実装者が知見を語る
認証は単純な概念で、別の言葉で言えば本人確認です。Web サイトにおける本人確認の最も一般的な方法は ID とパスワードの組を提示してもらうことですが、指紋や虹彩などの生体情報を用いた本人確認方法もありえます。どのような確認方法だとしても (ワンタイムパスワードを使ったり、2-way 認証だったりしても)、認証とは、誰なのかを特定するための処理です。開発者の言葉でこれを表現すると、「認証とは、ユーザーの一意識別子を特定する処理」と言えます。 一方、認可のほうは、「誰が」、「誰に」、「何の権限を」、という三つの要素が出てくるため、複雑になります。加えて、話をややこしくしているのは、この三つの要素のうち、「誰が」を決める処理が「認証処理」であるという点です。すなわち、認可処理にはその一部として認証処理が含まれているため、話がややこしくなっているのです。 認可の三要素をもう少し現場に近い言葉で表
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Home 2024 - OpenAPI Initiative
harold-spm.com