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を設計してみるとどんなインターフェイスがいいのか、どんな形式がいいのかといった疑問が次々と出てきます。
RSpecでRequest Describer - Qiita
WebアプリケーションのHTTPレベルでの振る舞いに対してテストを記述するとき、皆さんはどのような考えを持ってテストコードを記述しているでしょうか。この投稿では、この手のrequest-specと呼ばれるテストについて考えながら、テストを書くときの幾つかの方針と、RSpec::RequestDescriberを利用してテストコードを簡略化する方法を紹介します。 request-specとは request-specという、HTTPにおけるリクエストとレスポンスの組み合わせを、言わばブラックボックスとして扱うテスト形式の呼び名があります。リクエストを入力、レスポンスを出力として扱い、ある入力に対して期待される出力が返されるかどうかをテストします。rspec-railsの中では、request-specに対して以下の説明が与えられています。 Use request specs to speci
【Rails】RSpecと三種の神器でらくちんWeb APIテスト - Qiita
はじめに 3月頃，『【Rails】RSpecでWeb APIのテストでハマったところ①』という初心者丸出しな記事を書きました． あれから9ヶ月ほど，お仕事としてRailsに触れたりしたため知見・スキルも向上してきたと思います． そして今，前述の記事を見直したところ恥ずかしくて顔を覆いたくなる感じになったので改めてWeb APIのテストについて書いていきます． APIのテスト？ そもそもWeb APIのテストはどこに書くの？ってところからですが… Controller SpecではなくRequest Specに書いていきます． Use RSpec Request Specs Since we’ve established that we’ll be using Rack::Test to drive the tests, RSpec request specs make the most s
APIドキュメントを実装と乖離させないために - Qiita
内部用APIであるか外部の開発者向けのAPIであるかに関わらず、ドキュメントと実装との乖離は極力避けたいものであるが、注意深く開発を進めない限りこの状況は容易に起こり得る。何が乖離を引き起こし、どうすればこの状況を回避できるのか考えながら、JSON Schemaの利用例を紹介する。なおこの投稿では、HTTP経由でデータの通信を行うような狭義のAPIのことをAPIと呼ぶことにする。 同じ情報源を参照する APIドキュメントと実装が同じ情報源を参照するようにすれば、論理的に関連した要素は統一的に変更され、これらの変更は完全に同期が取れたものになる。つまり、変更時に乖離が生じにくくなる。但し情報の見せ方によって乖離が発生する可能性は十分にだろうし、乖離が発生するのは理解しようとする側の認識の問題であるから、論理的に全く起こり得ないということではない。 この参照の形には、両者が別の情報源を参照する
全てがJSONになる - ✘╹◡╹✘
TL;DR JSON Schemaを使ってこういうことが実現可能になった。 ダミーAPIサーバの提供 ドキュメントの自動生成 APIクライアントの動的定義 APIサーバのバリデータの動的定義 APIサーバのレスポンスの自動テスト JSON Schemaとは JSON SchemaというのはあるJSONのデータ構造を記述するための方法および書式の仕様で、 JSON SchemaもJSONで記述される。 これを利用すれば、リソースベースの(=RESTfulライクな)APIの仕様が簡便に記述できる。 例えば、我々のAPIはレシピとユーザというリソースを扱っていて、 それぞれCRUDのAPIを備えており、レシピはidとtitleとdescriptionという属性を持つ、 という旨をJSON Schemaで表現できる。 なんで最近ちょっと流行ってんの Mobile First、 Service Or
JSON Schemaを少しでも楽に使う - Augmented Usamimi
@izumin5210 こういうのある interagent/prmd https://t.co/QW9oCp0Lzh— ダメになるクッション (@r7kamura) December 22, 2014 gems prmdでscaffold jdocでドキュメント生成 rack-json_schemaでmockサーバ作ったりvalidationしたり… # Gemfile # ... gem 'rack-json_schema' group :development do # ... gem 'prmd' gem 'jdoc' end usage yamlで書けるのは楽．jsonよりは…． # doc/meta.yml --- "$schema": http://json-schema.org/draft-04/hyper-schema description: A schema forG
Pocket Developer Program: Pocket API: Retrieve
Pocket API: Retrieving a User's Pocket Data Pocket's /v3/get endpoint is a single call that is incredibly versatile. A few examples of the types of requests you can make: Retrieve a user’s list of unread items Sync data that has changed since the last time your app checked Retrieve paged results sorted by the most recent saves Retrieve just videos that the user has saved Search for a given keyword
階層化されたデータをHTTPのGETリクエストのパラメータに含める方法。
･･･が知りたい。 POSTのリクエストボディのシリアライズの方法はかなり柔軟なんですが、GETはURLにクエリパラメータとして添えるしかないので、柔軟性が低いです。 URLエンコードして渡す。 たとえばですが、四則演算があったとして、これをHTTPリクエスト経由で答えを求めたいとします。 (1 + 2) * 3 この計算式をURLエンコードして渡すというのがひとつです。 /api/calculate?query=%281%20%2B%202%29%20%2A%203 オブジェクトは渡しにくい あまり例えがよくないかもしれないですが、この計算式は階層構造をもっていて、JavaScriptのオブジェクトで表現すると以下のように表現できなくもないです。 var query = { operator : 'multiply', values : [{ operator : 'plus', val
最高の検索にまた一歩近付きました - Qiita Blog
こんにちは。珍しくブログ記事に煽ったタイトルを付けてみて、若干不安を覚え始めている r7kamura です。今回、QiitaとQiita Teamの検索機能に改善を加えたため、追加された新機能についてお知らせします。 ストック数で検索stocks:>1000 tag:Ruby のように、ストック数を指定して検索できるようになりました。この検索クエリは、1000件より多くストックされていてかつRubyタグが付けられている記事を検索します。stocks:>1000 の他、stocks:42 や stocks:<3、stocks:>=250 のような指定も可能です。 投稿日時で検索created:>=2015-05-01 tag:Swift のように、記事の投稿日時を指定して検索できるようになりました。この検索クエリは、2015年5月1日以降に投稿されていてかつSwiftタグが付けられている記事
WebAPIリクエスト仕様書としてcurlコマンドのご提案 - Qiita
WebAPIの仕様を記述する方法はいくつかあると思う。 普通に日本語で記述する JSON Hyper-Schema、WADL、RAML、Swaggerなどを使う 仕様書の代わりにプログラムを書く HTTPメッセージそのものを記述しておく でも、文法にばらつきがあったり、読みにくかったり、ツールのセットアップが面倒だったり、どれもイマイチな所があって、手軽な方法が欲しいと思っていた。 何気なくcurlコマンドのオプションを調べていたら、「もうこれでAPIドキュメント扱いにしちゃえばいいんじゃね？」と思えてきたのでメモしておく。 curlコマンドのおさらい curlコマンドはlibcurlの付属コマンドで、最近のUnix系OSなら大抵最初から入っていると思う。コマンドの詳細はmanを読んでいただければ。 cURL - How To Use （マニュアルページ日本語訳） curlコマンドのオプシ
HTML5 History APIで非同期通信時にURLを変更する方法 | 株式会社LIG(リグ)｜DX支援・システム開発・Web制作
こんにちは、フロントエンドエンジニアの店長です。 先日記事が出てましたが改めて自己紹介します。 大学卒業後はカフェで仕事をしていたのですが、退職して1年半ほどWebデザイナーをしていました。そして、LIGにはフロントエンドエンジニアとしてジョインすることに。 お察しのとおり、店長というアダ名はカフェで働いていたためです。 今後ともよろしくお願いします。 さて、今回はHTML5のHistory APIについてお話したいと思います。 History APIについて History APIには以前からブラウザの履歴（スタック）を行き来する機能があったのですが、HTML5でさらに以下のような機能が追加されました。 画面を遷移せず、履歴に新たなURLを追加する。 現在のページの履歴を変更する。 ブラウザの戻る・進むボタンをクリックしたときにイベントを検知する。 このような機能がどんな場面で使われてい
Garage RailsでOAuth認証付きのRest APIをお手軽開発！
CookpadさんがOSSで先日OSSで公開されたGarageはRestfulなAPI + OAuth(Doorkeeper)をワンストップで提供してくれるgemです。 ちょうど触る機会が出てきたので、今回四苦八苦しながら使ってみたのでそのメモです！ 🎂 今回のサンプル実装今回はOAuthで認証して、次のシンプルなAPIにアクセスできるようにするまでのサンプルを作成します。 GET /v1/users => ユーザーのリスト出力 GET /v1/users/:id => 個々のユーザー情報の出力 🎃 Gemの追加Gemfileに以下を追加して、bundle install。 gem 'garage', github: 'cookpad/garage' gem 'responders', '~> 2.0' # If you use Rails4.2+ group :development
Web API: The Good Partsを読んだ - AnyType
Web API: The Good Parts 作者: 水野貴明出版社/メーカー: オライリージャパン発売日: 2014/11/21メディア: 大型本この商品を含むブログ (1件) を見る 業務ではiOSアプリとバックエンドの開発を両方担当しているので、APIの設計を何回かやってきた。しかし、自分なりのやり方でやってきた部分が多かったので、最近発売されたWeb API: The Good Partsを読んでちゃんとした設計について学ぶことにした。 得られた学びをメモとして残す。 HATEOAS HATEOAS（Hypermedia As The Engine Of Application State）という設計方法を初めて知った。HATEOASではまず、サーバー側はレスポンスに関連するエンドポイントを含め次にアクセスするAPIを簡単に辿れるようにする。クライアント側は最初のエンドポイント以
Instagram API を使う | M-note
1. Instagram Developer Documentation にアクセスして、 Register your application ボタンをクリックする。（要ログイン） 2. デベロッパー登録をする（ URL・電話番号・APIを使って何を構築するか 、をそれぞれ記入）。 3. Manage Clients 画面 > Register a New Client ボタン > Register new OAuth Client 画面で、 アプリケーション名・（アプリケーションについての）説明・WebSite・OAuthのリダイレクトURL をそれぞれ記入。（全項目入力必須、後で編集可能） 4. 取得したClientIDを使って情報を取得（JSON形式）。
#13 フロントエンド制作に華を！ 面白いWebAPI 7選 - KAYAC engineers' blog
こんにちは。 カヤックに新卒で入社し、フロントエンドエンジニアとして スロット制作を中心とした活動を続けている田島です。 どうぞお手柔らかによろしくお願いします。 さてさて、Webのフロントエンドエンジニアの場合、 何か作りたいアイデアを思いついてから世に公開するまでのスピードが コピーライターに次いで早いです。 また、リッチなコンテンツや大量のコンテンツを扱って何かしようというときには WebAPIをうまく活用すれば、自前でデータベースを作らずとも ササッと作って公開することもできます。 今回は、そうしたフロントエンド制作を豊かにするWebAPIの中から特に 面白いと思うものを7つ選び、実例を交えて紹介していきたいと思います。 1. MediaWiki API http://ja.wikipedia.org/w/api.php Wikipediaの情報を取得できるAPIです。 このAPI
Web APIを作るときに考えること。 - パルカワ2
この記事はPepabo Advent Calendar 2014の11日目の記事です。 前日は、tnmtさんのVagrantのshell provisionerでApacheのビルド済tarボールをOSバージョン毎に作る術でした。 はじめに 今回は、Web APIを作るときに考えることをまとめました。 本当は、社内向けに資料を作っていて、社内の勉強会とかで話せればいいか〜って考えていたんですが、アドベントカレンダーのネタが本当になくて困っていたのでこれを使います。 対象者 APIを作る時、と書いてますが、クライアント側の人にとっても知っておく必要があることなので、サーバ側の人・クライアント側の人両方が対象者です。 APIを作るときに考えること 「APIを作るとき」と言っても、色んな状況があります。 まずはそれを絞ります。 APIの種類 プライベートAPI アプリのAPIなど使う人が限定され
"Microservices"を読んだ
James Lewis氏とMartin Fowler氏による“Microservices”を読んだ．以前ざっと目を通したが，最近よく耳にするようになったのでちゃんと読んだ．以下はそのメモ． 概要 “Microservices” とはソフトウェアシステムの開発スタイルである 近年このスタイルでの開発を見てきて良い結果が出ている 初出は2012年の3月の“Micro services - Java, the Unix Way” Microserviceは一連の小さなサービスで1つのアプリケーションを開発する手法 それぞれのサービスは自身のプロセスで動いており，軽量な機構（e.g., HTTP API）を通じて情報をやりとりする これらのサービスは独立して自動デプロイされる 一枚岩として構築されるMonolithicスタイルのアプリケーションと比較すると分かりやすい 一般的なエンタープライズのア
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SSSSLIDE
いろいろなサービスのAPIをcurlで叩くときの認証の扱い - Qiita
Instagram APIでwebサービスを作りたい全ての人に向けて書きました
