Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? スプレッドシートを Web API 化するアプローチとして Google Apps Script を使ったやり方があります。 最近、人気記事になっているのがまさにそのパターンですね。 3分で API を作って世の中にデプロイするライブコーディング〜今日から君もスピードスターエンジニア〜 しかし、Google Apps Script を使った手法には次のような弱点があるため、簡易的なものにしか使えません。1 URLを自由に設定できない リクエスト数など各種制限 本記事では、サーバーやクライアントなど好きな環境からスプレッドシートを読み込む
作りました！ pixe.la これはなに？ お好きな数値を登録、その登録された数値情報に基づいて、アレのあれっぽくグラフを作れるサービスです！ アレのあれってのは、これのコレ↓っぽいやつです！ ↑commit回数をグラフにした場合のイメージ。 ↑プロダクトのデプロイ回数をグラフにした場合のイメージ。 ↑体重の変動（前日比）をグラフにした場合のイメージ。 どうやって使うの？ Pixela は、サービスのトップページ以外は全部 Web API のみで構成されるサービスです！なので、ユーザー登録からなにから、全部 API でおこないます！ $ curl -X POST https://pixe.la/v1/users -d '{"token":"thisissecret", "username":"a-know", "agreeTermsOfService":"no", "notMinor":"
ASP.NET Core プロジェクトで作成した Web API のドキュメントを Swagger を使って生成したいと思います。 開発環境 Mac OS X El Capitan Visual Studio Code Web API アプリケーションを準備する ASP.NET Core の Web API アプリケーションを作成済みの方はそのまま進んでください。もし作成していない場合は ASP.NET Core で Riot.js その１ - プロジェクトの作成 ASP.NET Core で Riot.js その２ - Server-side の部分を参考に実装して頂ければ幸いです。 パッケージの入手 今回は .NET で Swagger を利用するためのライブラリとして Swashbuckle を使います。 NuGet Gallery | Swashbuckle - Swagger f
Eureka EngineeringLearn about Eureka’s engineering efforts, product developments and more.
ヤマトビジネスメンバーズにAPI提供サイト「YBM For Developers」を開設 ～12月14日より、さまざまな事業者や開発者向けに、 “荷物を送る、受け取る”をより便利にするAPIを公開～ ヤマトホールディングス傘下のヤマト運輸株式会社（本社：東京都中央区・代表取締役社長：長尾 裕、以下、ヤマト運輸）は、12月14日より、ヤマト運輸が運営するビジネス向け会員制サービスのポータルサイト「ヤマトビジネスメンバーズ」に「YBM For Developers」を開設し、さまざまな事業者や開発者向けに“荷物を送る、受け取る”をより便利にするAPIを公開しますので、お知らせします。 １．背景 Eコマースの拡大やライフスタイルの変化に伴い、荷物を受け取るニーズが多様化しています。ヤマト運輸は、さまざまなお客さまのニーズに応えるため、商品購入時に全国のヤマト運輸営業所や取扱店を受け取り場所として
#AndroidでMicrosoft Translator Text APIを使って翻訳する ～実装編～ MicrosoftTranslatorTextAPIを使って翻訳するAndroidアプリを作ったので、 導入方法を備忘録として残しておきます。 こちらの記事では AndroidでMicrosoft Translator Text API を使って翻訳する ～準備編～ で取得したキーを使い、MicrosofTranslatorTextAPIでAndroidアプリに翻訳機能を実装していきます。 公式ドキュメント 1. APIトークンの取得 MicrosoftTranslatorTextAPIを使って翻訳するには、先にAPIトークンを取得する必要があります。 通信を行うのでAsyncTaskを継承したクラスを作成します。 package <パッケージ名>; import android.os
RESTful な URL にしよう 元記事 GET /tickets - チケットのリストを取得する GET /tickets/12 - 指定したチケットの情報を取得する POST /tickets - 新しいチケットを作成する PUT /tickets/12 - チケット #12 を更新する PATCH /tickets/12 - チケット #12 を部分的に更新する DELETE /tickets/12 - チケット #12 を削除する Google GET /events - 予定のリストを取得する GET /events/12 - 指定した予定の情報を取得する POST /events - 新しい予定を作成する PUT /events/12 - 予定 #12 を更新する PATCH /events/12 - 予定 #12 を部分的に更新する DELETE /events/12 -
CTO兼福岡オフィス立ち上げ担当として新アプリを作っている@edvakfです。 JSON APIを開発しているとこういう問題がありがちですよね。 仕様どおりにAPIの形式を作ったはずだけどなんか自信が持てない テストでいくつかのキーが存在するかの簡単なチェックはしてるつもりだけど、全部チェックするのは大変すぎる APIのControllerやViewをリファクタリングしたらレスポンスの形が変わってアプリがめっちゃクラッシュし始めた というのが怖くて誰もリファクタリングできなくなった APIドキュメントがメンテされない 知らない間にレスポンスのフィールドが増えてたけどドキュメントに書いてない これらを解決したい！と思って試行錯誤したら、スマートに解決することができました。この記事ではRailsのことについて書きますが、考え方は他の言語・フレームワークでも同じです。 なお、今回使ったgemのバ
最近公開されたGitHubのAPIは、GraphQLという形式に対応しました。今後はこちらが主流になっていくようで、既存のREST APIからGraphQLへのマイグレーションガイドも提供されています。 今回は、このGraphQLについて、実際にGitHubのAPIを叩きながらその仕組みを解説していきたいと思います。 GraphQLとは 歴史 GraphQLは、Facebookの中で2012年ごろから使われ始めたそうです。その後2015年のReact.js Confで紹介されたところ話題となり、同年"technical preview"のステータスでオープンソースとして公開されました。その後仕様が詰められ、2016年9月に晴れて"preview"を脱し公式実装として公開されました。これと同じタイミングで、GitHubからGraphQLバージョンのAPIが公開されています。 このあたりの経緯
こんにちは、バックエンドエンジニアのじょーです。大規模なサービスのAPIを開発する際に、ルールを決めずに開発していると無秩序なコードが散見される運用がしづらいAPIになってしまいます。また、ルールを決めたとしても共有が上手くいかないなどの理由で守られなくなってしまうこともあると思います。 本記事では、APIを運用しやすくするために、ただルールを決定しただけではなく、ルールを守るためにそれぞれ仕組み化をしたことを紹介します。 APIのレスポンスを統一する デコレーターを使ってレスポンスの定義を綺麗に書く パラメーターを統一する Validatorによりパラメーターの明記を強制する コーディング規約を守る LinterとSideCIを導入して修正とレビューの自動化 Linterのルールを適度に調節する 1. APIのレスポンスを統一する ここで言うAPIのレスポンスを統一するというのは、返すA
〈追記 2019年1月〉 残念ながら YQL終了のアナウンス がありました。 On Jan. 3, 2019, YQL service at http://query.yahooapis.com will be retired. YQL based services that use http://query.yahooapis.com, including users of http://datatables.org, will no longer operate. Yahoo Weather API users see the tweet below for info about continuing your service. — Y! Developer Network (@ydn) December 31, 2018 とっても便利だった Google Feed API ですが、復
※OpenWeatherMapの取得可能情報種類は5 day / 3 hour forecast APIでの情報 ※Weather Undergroundの取得可能情報種類はconditions APIでの情報 OpenWeatherMap http://openweathermap.org/ ・APIは数種類公開されていますが、無料で利用可能なものは現在の気象情報が取得できるもの、3時間毎/5日間の予報が取得できるものの2種類です。 ・空港や都市部に設置されているものから個人観測所も含め40,000以上の観測所からデータを収集しています。データソースとして日本気象庁、アメリカ国立気象局、カナダ気象庁、ヨーロッパ中期予報センター等が挙げられています。 Weather Underground https://www.wunderground.com/ ・アメリカ国内外合わせ60,000以上の
今日では HTTP(s) で API が公開されることは当たり前の時代ですが、エラーをアプリケーションにどう伝えるかは、個々の API の設計に依存していました。特に、HTTP ステータスコードは有限であり、元々持っている意味があるので、自由に使うことはできません。API はそのドメインごとにもっと複雑で細かなエラー情報があるはずで、それらはレスポンスボディに載せてアプリケーションに伝えることになりますが、その書式に規定は今までありませんでした。 HTTP API にて、アプリケーションにエラー情報を伝達するための（レスポンスボディに載せられる）標準的な形式が、RFC7807 Problem Details for HTTP APIs で定められています。適用例としては、以下のようになります。 HTTP/1.1 403 Forbidden Content-Type: application
はじめに モチベーション 異なるエンドポイントで、大体似たようなレスポンスなのに、 キー名が違う... キーが多かったり少なかったりする。。 というような、Web API (主にjsonを返す) を作っていてよく問題になる現象。 このような問題に対してのアプローチとしてはいくつかある。 例えば、formatする関数を用意して、必ずレスポンス返却前にそれを呼んで返す、のような運用的な解決手段。 が、 あまり強制力がない 宣言的ではなくどうしても手続きっぽくなる というところで、ややイケてなさが残る。 そこで、API全体としてもっと強力な制約を課し、宣言的にやることで、レスポンスの形を完全に安定させたい。 そのために導入したのが、 (厳密な)リソース指向API と呼んでいるもの。 それ自体は何の新規性もないのだが、2ヶ月くらい運用してみて割と上手く行っているので、その気持ちと実装のことを書く。
Twitter streaming api cybozudev api Restとは RESTはREpresentational State Transferの略。 RESTの原則に従って実装されているシステムのことを、RESTfulと呼ぶ。 RESTの世界では、ネットワーク上のコンテンツ(リソース)を一意なURLで表すのが基本。 各リソース（URL）に対してPOST、GET、PUT、DELETEでリクエストを送信する。 上のリクエストは、CRUD（Create、Read、Update、Delete）に紐付ける。 大体、レスポンスをXMLやjsonの形式で受け取る。 Restの設計 URL設計 リソースを名詞であらわす。例: /user/10 /song/5 video/7 POST は create, GET は read, PUT は update, DELETE は delete。H
REST APIを設計する場合に、エラーをどのステータスコードで返却するか議論になることがあります。例えば、以下のような場合が挙げられます。 キー指定のリクエストでDBにデータがない場合（例： GET /books/1 ） 一覧のリクエストでDBにデータがない場合（例： GET /books ） 必須項目がない、型が合わないといった場合（例： GET /books/find?count=bar ） ビジネスルールに違反する場合（例： POST /purchase ） 実行時エラー（例： NullPointerException ） クライアントが適切にエラーを処理できるように、レスポンスにエラー原因を入れることが一般的です。では、ステータスコードは何がいいのでしょうか。HTTPのステータスコードはRFCで定義されているし、RESTの考え方はWebや書籍にまとまっていますが、あくまでも考え方
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? これは Enchant の開発者である Vinay Sahni さんが書いた記事「Best Practices for Designing a Pragmatic RESTful API」1を、ご本人の許可を得て翻訳したものです。 RESTful な WebAPI を設計しようとすると、細かなところで長考したり議論したりすると思います。また、他の API に倣ってやってはみたものの、本当にそれでいいのか、どうしてそうしているのか分からない、何てことも少なくはないと思います。 この記事では、そのようなハマリどころについて Vinay さん
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く