[PR] 独自ドメインは早めの取得がおすすめ!
【API Blueprintの使い方】Web APIの仕様書を書く・読む・実行する できればドキュメント書きたくないなー。はやくAPI実装したい!俺の頭の中に全部仕様入ってるから!俺が仕様だ! ... その仕様、API Blueprintでドキュメントにおこしませんか? はじめに デバイスが多様化し、その違いを吸収する統一的なインターフェースが求められる昨今、Web APIはその回答のひとつといえます。弊社でも、モバイルアプリとWeb APIを組み合わせてサービスを構築することがあります。 Web APIが登場する開発では、モバイルアプリ(APIクライアント)メンバーと、APIサーバメンバーのコミュニケーションが不可欠です。開発を円滑に進めるために、APIの仕様書 が必要になります。お互いがAPIの仕様を想像して勝手に開発を進めたのでは、いざ結合したときに悲惨な結果になることが目に見えてい
(編注:2016/7/29、頂いたフィードバックを元に記事を修正いたしました。) APIをデザインするということは、科学であり技術でもあります。多くの頭の良い人たちが失敗を重ねてきました。成功している人たちは、APIの主な目的を念頭においてデザインしているのです。その目的とは、「開発者たちをウンザリさせる」ということです。 親愛なる仲間たち、その崇高っぽい追求を称えるべく、「APIデザインにおける七つの大厄介」を共に数え上げようではありませんか(私がしたことを見てください)。 リスティクル(箇条書き形式の記事) を書くつもりはないのですが、少なくともタイトルは 教養ある宗教的文献が参照元 です。 まず、ルールを決めましょう。ここでは、成功し、きちんと機能しているAPIを取り上げます。ですから、「動かない」とか、「大量のセキュリティホールがある」といったことは厄介ごとに数えません。「致命的」
以下なドキュメントを発見しておりまして。 HTTP API Design Guide なんとなくメモをとってみました。 Contents として以下が列挙されています。 適切なステイタスコードを戻しなさい 戻すことができる全てのリソースを戻しなさい リクエストボディに含まれるシリアライズされた JSON を受け付けなさい ID じゃなくて UUID 使った方が良いですよ 標準的なタイムスタンプを使いましょう UTC 時刻は ISO8601 フォーマットで使いましょう 一貫性のあるパスフォーマットを使いましょう 小文字とダッシュを使いましょう 外部キーのリレーションは入れ子に 利便性をはかるため non-id dereferencing をサポートしなさい エラーの場合のレスポンスボディについて ETag ヘッダを含めなさい Request-Id ヘッダを API レスポンスに含めなさい P
API Development forEveryone Simplify your API development with our open-source and professional tools, built to help you and your team efficiently design and document APIs at scale. Find your toolRead the docs Trusted by Empowering API Development Streamline your workflow with unparalleled API specification support Swagger places API specifications such as OpenAPI, AsyncAPI, and JSON Schema at the
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
Ruby (on Rails), Mobile Development, Android/iOS, Rubymotion, API development tutorials An updated version of my previous tutorials on building an authenticated JSON API with Ruby on Rails In this tutorial I will build a small web application that provides a JSON API to manage customers through a REST interface. The requests to the endpoints will be authenticated through a token based authenticati
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を設計してみるとどんなインターフェイスがいいのか、どんな形式がいいのかといった疑問が次々と出てきます。
ユーザーの現在位置を取得現在位置を取得するサンプルデモを見るには、下記ページにアクセスして下さい。このブログがあなたの位置情報を取得してもいいか、という確認が表示されるので、許可すると、あなたの現在位置(緯度、経度の座標)の取得を開始、表示します。 サンプルデモを見る 現在位置を取得するには、ユーザーのブラウザが、Geolocation APIという機能に対応している必要があります。Geolocation APIとは、簡単に言うと、端末の位置情報をやり取りするシステムです。GPSに対応しているスマホだけでなく、現在位置を設定できるデスクトップPCでも利用可能です。 判別方法は簡単です。Geolocation APIに対応している端末の場合、navigator.geolocationというオブジェクトが最初から存在するので、これの有無で判別すればいいだけです。 JavaScript // G
9月18日の RubyKaigi 2014 (1日目) で “Hypermedia: the Missing Element to Building Adaptable Web APIs in Rails” というタイトルの発表をしました。 Hypermedia: The Missing Element to Building Adaptable Web APIs in Rai… from Toru Kawamura 時間オーバーしてしまったのが反省点ですが、発表後にまわりの方々から良かったという言葉をいただいて、Twitterなどを見ても好評だったようで、嬉しい限りです。ありがとうございます。 詳しい内容については、るびまに載せる予定なのでそちらに譲るとして、要旨は、“RESTful Web APIs” (O'Reilly) に書かれている内容から、エッセンスを自分なりにまとめたものです
「プログラミング言語Java」「Effective Java」などの翻訳で有名な、柴田芳樹さんの新たな訳書である「APIデザインの極意」を読みました。 APIデザインの極意 Java/NetBeansアーキテクト探究ノート 作者: Jaroslav Tulach,柴田芳樹 出版社/メーカー: インプレスジャパン 発売日: 2014/05/23 メディア: 単行本(ソフトカバー) この商品を含むブログ (4件) を見る 「APIデザインの極意」は、NetBeansの生みの親で、初期のアーキテクトであるJaroslav Tulach(ヤロスラフ・ツゥラッハ)が著者で、NetBeansの開発で得た経験や教訓を纏めたノートが元になって書かれた書籍です。 従来のデザインパターンでは解決できない、後方互換性を維持しながらライブラリを発展させる設計手法について書かれています。 読んだ感想としては、GoF
2013年のいま、API界隈が熱い! 今年に入り、官公庁の統計データやNHKの番組情報など、今までなかなか利用できなかったデータがAPIとして扱えるようになってきました。このエントリでは現在公開されているAPIを一覧でまとめます。いま使えるAPIはこれだけ読めば大丈夫。2013年の最新マッシュアップ事情をあますとこなく網羅します! HOT! API 総務省 次世代統計利用システム(国勢調査、人口推計、就業構造、企業統計、物価統計 etc.) NHK番組表(※未公開) 行政・自治体・公共サービス 郵便番号 郵便番号検索API(郵便番号 → 住所) 郵便専門ネット(郵便番号 → 住所、郵便番号の簡易存在チェック) ぽすたん(郵便番号 → 住所、住所 → 郵便番号) IW3 PROJECT(郵便番号 → 住所、住所 → 郵便番号) 宇宙 Google+ JAXA PR(※現在一部の学生に限定公開
最近乱立している「モバイルアプリのバックエンド(Web API)に特化したサービス」に興味があったので、いろいろ試してみた。 「モバイルアプリのバックエンド(Web API)に特化したサービス」と書いたけど、まだまだそんなに一般的ではないのでBaaS(Backend as a Service)とかCloud Hosting とかいろんな呼ばれ方をしている && サービスによって提供する領域も違う。まあとくに定義はしないので気になったらその都度公式のヘルプでも読んでみて。本稿では呼びやすいのでBaaS と表記します。 BaaS とは? 最初に後程も紹介するdonayama さんのCocoafish の紹介エントリの一節がわかりやすいと思ったので引用します おそらくどのようなサービスであっても「ユーザ管理」をすると思いますが、ひとことにユーザ管理といっても、(場合によっては招待状による招待→)
Ruby on Rails 7.1.3.4 RDOC_MAIN.md railties/RDOC_MAIN.md Last modified: 2024-06-04 18:21:34 +0000 Welcome to Rails What’s Rails? Rails is a web-application framework that includes everything needed to create database-backed web applications according to the Model-View-Controller (MVC) pattern. Understanding the MVC pattern is key to understanding Rails. MVC divides your application into three laye
タイトルは釣りです。 免責 公式に公開されているものではないので、むやみに使わないでください。 何かしらのアプリケーションで利用する場合は当然、問い合わせなどをして許可を得るべきです。 本題 Ginger というサービスが先ごろ公開されてまして、一言で言うと「空気読んで誤訳を直してくれるサービス」って感じです。 細かいニュアンスとかをよしなに修正してくれて、エレガントな英語 に変換してくれるらしい!すばらしいサービスですね。 いまのところは、ブラウザの拡張機能が主であとは Windows の Office 向けのものがあるようです。 で、 ブラウザか・・・有料でいいからVim版が欲しい・・・ : 「もう前置詞に迷わない」──「ネイティブレベル」の英語が書ける英文チェッカー「Ginger」日本上陸 - ITmedia ニュース itmedia.co.jp/news/articles/… —
過半数の開発者が平均で3つ以上のAPIのインテグレーションを実装していると言われている昨今、「使い辛い設計のAPI」を実装するのは開発者にとっては頭の痛い問題ではないでしょうか? Programable Web上に投稿されたAPIのワーストプラクティスに関する記事が国内外の開発者の目に止まったようです。この記事によると悪いAPIに見られるプラクティスは下記のようなものだそうです。 貧弱なエラーハンドリング HTTPのルールを無視したREST API 裏に潜んだ生のデータモデルの露出 セキュリティの複雑さ ドキュメント化されていない予期せぬリリース 貧弱なデベロッパエクスペリエンス MVCフレームワークが良いAPIにしてくれるという思い込み 開発すれば使ってもらえると見なすこと 不十分なサポート 貧弱なドキュメンテーション APIを利用するだけでなく、APIを提供する場合に上記のようなポイン
InstagramグラフAPIInstagramグラフAPIは、アプリのユーザーが自分のInstagramビジネスアカウントおよびInstagramクリエイターアカウントのデータにアクセスすることを許可します。このAPIを使用して、メディアの取得と公開、メディアへのコメントの管理と返信、他のInstagramユーザーが@メンションしたメディアの特定、ハッシュタグ付きのメディアの検索、他のInstagramビジネスやクリエイターに関する基本メタデータと指標の取得を行えます。 Instagram基本表示APIInstagram基本表示APIは、アプリのユーザーが自分のInstagramアカウントの基本プロフィール情報、写真、動画を取得することを許可します。このAPIは、ビジネスおよびクリエイター以外のInstagramユーザーを対象にしています。メディアの公開、コメントのモデレーション、@メン
Geolocation API W3C Editor's Draft 04 June 2024 More details about this document This version: https://w3c.github.io/geolocation-api/ Latest published version: https://www.w3.org/TR/geolocation/ Latest editor's draft:https://w3c.github.io/geolocation-api/ History: https://www.w3.org/standards/history/geolocation/ Commit history Test suite:https://wpt.live/geolocation-API/ Implementation report: ht
Geolocation API W3C Recommendation 01 September 2022 More details about this document This version: https://www.w3.org/TR/2022/REC-geolocation-20220901/ Latest published version: https://www.w3.org/TR/geolocation/ Latest editor's draft:https://w3c.github.io/geolocation-api/ History: https://www.w3.org/standards/history/geolocation Commit history Test suite:https://wpt.live/geolocation-API/ Impleme
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く