本当に使ってよかったOpenAPI (Swagger) ツール | フューチャー技術ブログ
サードパーティ製のツール本家からは上述のツールが提供されていますが、サードバーティ製の様々なツールが世の中には存在します。 エコシステムが成熟しているのもSwaggerを利用するメリットの1つですね。 https://openapi.tools/ 冒頭のとおり、このサードパーティ製のツールの中で実際に利用して良かったツールを3つご紹介したいと思います。 Stoplight Studiohttps://stoplight.io/studio/ 1つ目のツールは「Stoplight Studio」というAPI仕様を記載するためのGUIエディタとなります。 今までSwagger Editorを利用してYAMLを書いていたそこのみなさん、YAML筋力はもう必要ありません。 Design APIs 10x faster の謳い文句どおり、Stoplight Studioを使えばGUIで直感的に、高速
APIのエラーハンドリングを見直そう - WebPay Engineering Blog
ここ数ヶ月にわたって、WebPayはAPIのエラーにまつわる変更を少しずつ行ってきました。 それに付随してドキュメントも拡張しましたが、変更の背景について十分に説明できていない部分がありました。 この記事では、最近のエラーに関連した変更の背景を紹介し、今後どのようにエラーをハンドルすべきか説明します。 記事の内容は執筆時点のものであり、今後同じようにエラーやAPIの変更を行うことがあります。 変更があっても記事の内容はその時点の内容を保持し、ウェブサイトのドキュメントのみ更新します。 必ずウェブサイトのドキュメントを合わせて参照し、手元で動作確認を行ってください。 エラーはなぜ起きるのか WebPayのAPIは、リクエストされた操作ができなかったときにエラーを返すように設計しています。 可能なかぎりエラーにならないような設計、実装を心がけていますが、エラーは絶対に避けられません。 例えば、
らくらくシーケンス図：WebSequenceDiagrams #apijp - Groovyラボ
これはWeb API Advent Calendar 2014、7日目のエントリです。知っている方も多いと思いますが、ツールの小ネタで。 Web APIを扱っていると、認証やマッシュアップのフローの記述など、簡単なシーケンス図を書きたくなる場合がよくあります。こんなときにオススメなのが、カナダのHanov Solutions社が提供する便利なWebサービスWebSequenceDiagrams。 次のようなシンプルなテキストを書くだけで： title GWでのmashup アプリ->GW: POST 郵便番号 GW->サービスA: GET /郵便番号 サービスA->GW: 住所(JSON) GW->サービスB: POST 住所 サービスB->GW: 緯度経度(XML) GW->アプリ: 緯度経度(JSON)次のようなイメージを生成してくれます： 基本的に無償で使えますし、生成した図は直接リ
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の設計、実装、レビュー、運用について細かく書かれていま
クラウドサービスの Web API とそのユースケース #apijp
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
HTMLでWeb APIをつくる - Qiita
シングルページアプリケーションやモバイルアプリなどの普及により、サーバサイドではJSONを出力するWeb APIの必要性が高くなってきています。みなさんはどのようにWeb APIを作っているでしょうか。 JSONはビュー RailsでJSON APIを定義する時、素のままでやろうとすると コントーラでto_jsonを呼んだり、モデルにas_jsonを定義したりすることになるかと思います。 モデルに書くとAPIによって出力内容を変えたい場合にとても苦労します。 API数が増えれば増えるほどモデルが複雑になっていきます。 APIレスポンスとしてのJSONはコントローラやモデルに書くべきでしょうか？ ビューに書いた方が自然ではないでしょうか？ これはRailsでの話ですが、Railsに限らず、フレームワークを使ってWeb APIを作るときに一般的にあてはまることだと思います。 変化に強い、再利用
10 Reasons Why Developers Hate Your API
Clojure's Journey: From Simplicity to Enterprise Maturity Jordan Miller discusses the evolution of the Clojure ecosystem, from Rich Hickey's initial vision tackling complexity to its current status as a mature enterprise solution. He explains key philosophies, highlights pivotal moments like the "Simple Made Easy" talk, and showcases the vibrant Clojure community and its innovative tools.
API Meetup Tokyo #1
SOAP、REST、XML、RSS、OpenSearch…などの歴史の話。 OpenSearchは、今amazon CEOのベゾスが公開したってのは知らなかった。 あと、当初はhttpはapiに使うプロトコルとして考えられてなかったと。 言われてみればwebのブラウジングのプロトコルだから、そういうapiとしての使われ方ってのは確かに想定外(？)だったのかなぁ。 そして、ajaxの”発見”。 発見という言葉使われてるの見てなるほどなと思った。 確かに既存の技術の組み合わせだけで、非同期処理ってのは画期的だったんだろうなぁ。 あとlivedoor readerはajaxを利用したシングルページアプリケーションとして当時素晴らしいものだったと言っていた。 Twitter4Jの作者の方。 ストリーム型APIの仕様というのが面白かった。 レートリミットがなく、cometやwebSocketは使わず
続・リトライと冪等性のデザインパターン - リトライはいつ成功するか - Blog by Sadayuki Furuhashi
三度の飯よりエラー処理。古橋です。 大変好評をいただいた序章リトライと冪等性のデザインパターンの続編です。 前回はほぼ前置きでしたが、今回は冪等でない操作を冪等にする具体的なテクニックもまとめていきます。 パターン２：エラーを区別してDELETEを冪等にする リソースに常に一意なIDが振られていれば、Deleteを冪等にするのは難しくない。そもそも同じリソースを2度削除することはできない。 一つ注意するべきなのは、削除されたリソースのIDが再利用されるケースでは、Deleteの冪等性は保証されない。例えば、kill -KILL <pid> コマンドはDelete系のAPIと考えられるが、pidは再利用されるので、何度も繰り返すと意図しないプロセスを殺してしまう可能性がある。 一般にIDの生成は非常に難しい問題だが、Deleteに関してのみ言えば再利用されなければいいので、単調増加する整数（
Ten Reasons Developers Hate Your API
APIs are everywhere today and can be a great building block of modern applications. But all too often APIs are not truly great. Rather than love your API, developers curse it. How can you avoid that fate? In this session we'll look at the most common mistakes API providers make and you can avoid making them too. Do you offer a bad developer experience (DX)? Poor, inconsistent API design? Unreliabl
XMLのWebAPIを爆速で使いこなせるフレームワーク
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog Yahoo!デベロッパーネットワークの中野(@Hiraku)です。先日、爆速JSONPを使うと、JSONPのWebAPIを簡単に使いこなせることを示しました。 とは言っても、JSONPに対応していないWebAPIも数多くあります。ニュースAPI、知恵袋API…。これらは現時点ではXMLしか対応しておらず、爆速JSONPではブログパーツ化できません。 …いや、「ブログパーツ化できませんじゃなくて、とっととJSONPに対応しろよ」とお叱りを受けるところなんですが、実はXMLなら何でもJSONPに変換することのできる「YQL」というサービスがあり、これを使うことでカバーする方法があるのです！ YQLの説明は後にして、まずはデモをご覧くだ
koi_zoom1, オープンデータをやっている人は、過去にWSDLとかSOAPとかが上手く流行らなかった理由を知っておいた...
オープンデータをやっている人は、過去にWSDLとかSOAPとかが上手く流行らなかった理由を知っておいた方が良いと思う。 XMLがでてきて廃れてきた理由も。 結局、ちょっとリッチなCSVであるJSONのやりとりが今は主流。 LODってWSDLと同じ思想な感じがして同じ衰退の道をたどりそうなんですよね。 WSDLの方は「サービスをノードからたどれるようにした」のに対して、 LODは「データをノードからたどれるようにした」 でも、実際にノードをたどる必要はなくて直接そこからデータを抜き出すのが主流。 サービス同士をつなげようとしたのがWSDLで、でもプログラマは自分でプログラムを組んでサービス同士をつなげてしまう。 LODはデータ同士をつなげようとしていて、でも実際はプログラマは自分でデータをつなげる方が楽、と思いそうな気がするんですよね。 オープンデータの資料を読むとLODにするのが偉い的な書
日本の全エンジニアに捧ぐ！現在公開されているAPI一覧【2013年版】 | Find Job ! Startup
2013年のいま、API界隈が熱い！ 今年に入り、官公庁の統計データやNHKの番組情報など、今までなかなか利用できなかったデータがAPIとして扱えるようになってきました。このエントリでは現在公開されているAPIを一覧でまとめます。いま使えるAPIはこれだけ読めば大丈夫。2013年の最新マッシュアップ事情をあますとこなく網羅します！ HOT! API 総務省 次世代統計利用システム（国勢調査、人口推計、就業構造、企業統計、物価統計 etc.） NHK番組表（※未公開） 行政・自治体・公共サービス 郵便番号 郵便番号検索API（郵便番号 → 住所） 郵便専門ネット（郵便番号 → 住所、郵便番号の簡易存在チェック） ぽすたん（郵便番号 → 住所、住所 → 郵便番号） IW3 PROJECT（郵便番号 → 住所、住所 → 郵便番号） 宇宙 Google+ JAXA PR（※現在一部の学生に限定公開
自動タギングを可能にする高度な画像認識のWebサービスAPI『ReKognition』
自動タギングを可能にする高度な画像認識のWebサービスAPI『ReKognition』 『ReKognition API』は指定画像の内容を認識／判断し、その画像が何であるかを自動検出するテクノロジーを用いた統合的なWebサービスAPI。 PHP, iOS, Androidなど各種SKDとしても提供されており様々なプロジェクトやアプリ開発で利用することができます。 先ずはデモが用意されているのでそちらを見てもらうと分りますが、画像認識のタイプとしては大まかに画像の内容物を検出する「オブジェクト認識」と人間の顔を検出する「顔認識」の2種類があります。 「オブジェクト認識」はその画像内に含まれる物体や背景を認識して、それに該当する可能性の高いキーワードを列挙していきます。 一方、「顔認識」の方は単に顔の検出だけでなく、顔の各パーツを検知して性別や年齢あるいは表情から読み取れる感情までも検出する
You don't need API version 2 - yohei's diary
周回遅れ感が半端ないけどバージョニング関連で色々読んで・聞いて思ったことを書く。 APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight Kazuho's Weblog: 拡張可能なWeb APIの設計原則と、バージョン番号を使う理由について Rebuild: 35: You Don't Need API Version 2 (Kenn Ejima) rest - Best practices for API versioning? - Stack Overflow RESTfulなサービスのバージョンングから得られた知見 RESTとバージョニング 基本的にいわゆる狭義のRESTとAPIのバージョニングは何も関係ない。強いて言えば、HATEOASはバージョニングにも使えるよ、というのがREST信者の主張であるものの、それが正しい（というか実用的）かど
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
API機能 | 本システムについて | 次世代統計利用システム
WebAPIのこれまでとこれから
Writing Secure APIs
TechCrunch | Startup and Technology News
ヤフー、「Yahoo!ショッピング」のAPI約50本を公開 