RESTful#とは勉強会で(Railsでの)ルーティングの考えだし方の話をしました - moroのブログ
RESTful な設計って、ってマスタメンテ作るにはいいけどまともなサービス作れるの? という疑問に対して、結構やればアプリケーションできるので安心してください、という話をしました。 「独自研究」セクション以外はだいたいふつうに経験したことです。「独自研究」セクションはたぶん、今流行りのオーケストレイションレイヤをどうするかというところになるのかな、と。APIといいつつ、HTMLを返す話ばかりですが、これはAPIとHTMLをあえて区別せずそれは単にリプレゼンテーションが違うだけです、という意図でした。 転職してから初の社外発表が前職オフィスでやるというのが面白かったです。永和メンバーも結構たくさん会えてよかった。来てくださった方、開催をアレンジしてくださった方、ありがとうございました。
WebAPIリクエスト仕様書としてcurlコマンドのご提案 - Qiita
WebAPIの仕様を記述する方法はいくつかあると思う。 普通に日本語で記述する JSON Hyper-Schema、WADL、RAML、Swaggerなどを使う 仕様書の代わりにプログラムを書く HTTPメッセージそのものを記述しておく でも、文法にばらつきがあったり、読みにくかったり、ツールのセットアップが面倒だったり、どれもイマイチな所があって、手軽な方法が欲しいと思っていた。 何気なくcurlコマンドのオプションを調べていたら、「もうこれでAPIドキュメント扱いにしちゃえばいいんじゃね？」と思えてきたのでメモしておく。 curlコマンドのおさらい curlコマンドはlibcurlの付属コマンドで、最近のUnix系OSなら大抵最初から入っていると思う。コマンドの詳細はmanを読んでいただければ。 cURL - How To Use （マニュアルページ日本語訳） curlコマンドのオプシ
Flask | The Pallets Projects
Flask is a lightweight WSGI web application framework. It is designed to make getting started quick and easy, with the ability to scale up to complex applications. It began as a simple wrapper around Werkzeug and Jinja and has become one of the most popular Python web application frameworks. Flask offers suggestions, but doesn't enforce any dependencies or project layout. It is up to the developer
RESTのベストプラクティス | POSTD
現在ではREST APIはとても一般的な話題です。ほとんどすべてのWebアプリケーションの一部分となっています。シンプルで一貫性があり実際的なインターフェースは必須です。これは皆さんのAPIを他の人が使うことをとても容易にします。皆さんにとってはRESTの実践が日常的に感じられるかもしれませんが、RESTをあまり尊重しない人々もよく見かけます。これがRESTについて投稿するきっかけでした。 この記事にはRESTfulなAPIを設計する時に考慮すべきベストプラクティスがあります。 注意 : ここでのベストプラクティスは、私が過去の経験に基づいて良いと考える事例です。もし違う考えをお持ちであれば、お気軽にメールをくだされば意見交換できると思います。 APIのバージョンを示す APIのバージョンは必須であるべきです。これがあると時間が経ってAPIが変わっても影響を受けません。その方法の1つはUR
Java 9の新機能（予定）がオラクルから早くも発表に
今年の3月にJava 8が正式公開され、次のJava 9はおそらく2年後の2016年に登場すると予想されますが、そのJava 9に搭載される予定の新機能がオラクルから発表されたとInfoQの記事「Oracle Announces First Java 9 Features」が報じています。 InfoQが報じたJava 9の新機能は、JDK Enhancement Proposals（JEP）のインデックスページの中からバージョン9の予定になっているものとしても見つけられるようです。主なものをリストアップしました。 HTTP 2 Client HttpURLConnectionを置き換える予定で、HTTP 2.0とWebSocket対応 Light-Weight JSON API RFC7159に準拠したJSONデータの生成と読み込みを行うライトウェイトAPIを提供する Process AP
HerokuのAPIデザイン
Herokuが自ら実践しているAPIデザインガイドをGithubに公開した． “HTTP API Design Guide” このガイドは些細なデザイン上の議論を避けて，ビジネスロジックに集中すること目的としている．Heroku特有なものではなく，一般にも十分適用できる知見となっている． 最近は，モバイル向けにAPIをつくることも多いため，勉強もかねて抄訳した．なお内容は，HTTP+JSONのAPIについて基本的な知識があることが前提となっている． 適切なステータスコードを返す それぞれのレスポンスは適切なHTTPステータスコード返すこと．例えば，“成功"を示すステータスコードは以下に従う． 200: GETやDELETE，PATCHリクエストが成功し，同時に処理が完了した場合 201: POSTリクエストが成功し，同時に処理が完了した場合 202: POSTやDELETE，PATCHリク
SimpleHTTPServerの次の一歩としてFlaskを使う - Qiita
手元で実験のためにWebアプリのちょこっとしたプロトタイプを作るって時に、HTMLやCSSやJSなどを静的に配信したいだけだったら が楽ちんだということはだいぶ知名度が上がってきたみたいだけど、「あ、ちょっとデータを保存したい」とか思った時には静的配信だけだと力不足なんだよね。(GETパラメータに積んでログに残すという力技は除く) で、そういうシチュエーションになったので僕はFlaskで1ポモドーロ(25分)くらいで実装したんだけど、ふとFacebookを見たら似たようなシチュエーションでSocket使うとか言ってる人が居たのでこれはブログに書いておくべきことかーと思ったのです。 フレームワーク習得にかかる時間を大きく見積もり過ぎだよ。とりあえず25分間Quickstartをやってはどうか。Socketでサーバを実装するのに比べたら学習に掛かった時間はすぐにペイする。 http://fla
OHHTTPStubsを使ったiOSアプリ開発の進め方 - Qiita
概要 スタートアップiOS勉強会 #3 http://www.zusaar.com/event/4557003 自分もこれで話す内容についてずっと考えていて、laisoさんのスタートアップの人材戦略とは何かを読むと先にLTの内容を公開していたのでこちらも公開することにした。 10分以下のLTだと細かいことは多分話せないので、先におおまかに公開し実際のLTでは自分の特に話したいことを集中して話すようになるのではないかと思う（もしくはジョブズが成仏した話みたいに当日思いつきでぜんぜん違うことを言うかもしれないし、もしくは近所にガールズバーができたから行ってみたらビール一杯3080円だった話になるかもしれない）。 スタートアップに関する話について 経験上、iOSアプリ開発ではWebアプリ開発のようにいきなり大人数で開発を進めることがないので、iOSアプリ開発での技術的ノウハウやあるあるネタはスタ
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信者の主張であるものの、それが正しい（というか実用的）かど
拡張可能なWeb APIの設計原則と、バージョン番号を使う理由について
APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sightにはブコメしたのですが、Rebuild: 35: You Don't Need API Version 2 (Kenn Ejima)でも本件に言及があったようなので、少し一般論を書いておきたいと思います。 ■Web APIの設計原則について そもそも、良いAPIとはどのような特性をもつものでしょうか？ 一般的に、以下の２点が挙げられると思います。 拡張が容易である 拡張時に後方互換性を破壊しない ウェブの場合は、これに加え、 スケーラブルである HTTPに起因する問題に上手に対処できる ことが求められます。 前２者はウェブに限らない要件です。これを満たす設計手法としては、 リクエストおよびレスポンスのパラメータを拡張可能に 互換性を壊す拡張が必要な場合は、関数名を変える 古い関数は従来と同じ機能を
APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight
ちょっと前にTwitterでAPIのバージョニングをどうやるかみたいな話をしていたのですが、そのへんもやもやしているので少し整理しておきたいなと。 APIのURLを/api/v1/*とかってやるの、やめたほうがいいとおもうんだけどなぁ。いざv2を作るとなったときに、大量のコピペが発生して後悔するよ、って伝えたい。— Kenn Ejima (@kenn) February 28, 2014 さて、これについて色々と異論・反論も含めた意見が出たのですが、まずは、大昔にURL方式（＝コントローラ分割）でやってきて後悔したぼくが、（5年ぐらい前から）現在はどうやってAPIのバージョンを管理しているか？について紹介します。 基本原理としては、コピペが多発する根っこで分岐（＝コントローラ分割）じゃなくて、必要最小限のところで限局的に分岐するのがいい、という考え方に基づきます。 一言でいうと、「パラメー
YappoLogs: 2014年に向けた JSON API の実装の方向性と X-JSON-Status 改め X-API-Status header のご提案
2014年に向けた JSON API の実装の方向性と X-JSON-Status 改め X-API-Status header のご提案 追記 2014/11/20 14:00:00 わりと JSON やら XML やら各種フォーマットで API を運用している環境がある場合に JSON API の時だけ X-JSON-Status にすると XML とかの時と整合性取れないし、 X-XML-Status みたいのを量産するのは困る的なレビューを頂いたので X-JSON-Status をやめて X-API-Status にしました。 へたに JSON に限定するから REST とか JSON-RPC とかいわれるんや！ X-API-Status にしたら全部解決したし MessagePack な API でも使い回せるって songmu さん言ってた！ XML とかからどうやって引っこ抜
ブラウザが消滅して： APIベースのWeb - 檜山正幸のキマイラ飼育記 (はてなBlog)
「僕らが大好きだったWebはなくなるのかもしれない」において、「Webページ／Webサイトから構成される従来型のWebはなくなるのではないか」と述べました。 ここで、極端な想定として「Webブラウザが消滅してしまった」としましょう。これは、あくまで想定であって、未来予測をしているわけではありません。 汎用のブラウザに代わるのは、個別の機能を持ったアプリ群です。これらのアプリ（の多く）は、通信のインフラとしてインターネットを利用するので、インターネットはやはり必須で重要な存在です。 ブラウザがなければ、Webページから構成されるWebサイトは意味を持ちません。Webサイトはアプリのリモートバックエンドに置き換えられ、Webページはアプリの状態に取って代わられます。 アプリとそのリモートバックエンドは通信をするのでプロトコルが必要です。そのプロトコルは、HTTP（の発展形）がやはり主流でしょう
Hatena-Textbook/ios-app-development-with-web-api.md at master · hatena/Hatena-Textbook · GitHub
Web API を利用する iOS アプリ作成 iOS 開発 Bootcamp Introduction スマートフォン全盛期のいま、Web サービスもスマートフォンから利用される割合がどんどん高まっています。ユーザーはより便利で快適なアプリを求め、Web サービス事業者はそういったユーザーを少しでも満足させるため、日々努力しています。またスマートフォンアプリ開発を専業としていても、Web との関わりのないアプリではできることが非常に少なく、その様なアプリはいまやごくまれです。今日、Web アプリケーションとスマートフォンアプリは非常に密接な関係にあります。 Web アプリケーションとスマートフォンアプリ開発の両方を学ぶことは、そういった現在の Web をより広く見通すためには最適な課題であると言えます。どちらも学ぶことでその連関を知るだけでなく、開発の類似性や違いからより多くを学べるはず
Web API 設計のベストプラクティス集 "Web API Design - Crafting Interfaces that Developers Love" - フリーフォーム フリークアウト
移転しました http://please-sleep.cou929.nu/20130121.html
webRequest APIをざっくり理解する。(あるいはChrome拡張の作り方) – mzsm.me
昨日2月9日、Google Chrome 17の安定版がリリースされました。 このバージョンでの変更点の一つに、webRequest APIが正式に実装されたことがあります。 これまでこのAPIはexperimental(実験的機能)として実装されていましたが、今回晴れて正式なものになりました。 このAPIを使うと、Chromeが行う通信を監視して通信があるたびにイベントを実行したり、HTTPヘッダを書き換えたりすることができます。 Chrome 17では、User-Agentを他のブラウザに偽装することができる機能がDeveloper Toolsに付いたのですが、その機能もこのAPIを利用して実装されてい(ると思われ)ます。(Developer Tools自体もJavaScriptによって実装された“Webアプリ”なので、多分そのはずです) HTTPヘッダをいじれるというと不安に思われる
openkeyval.org - openkeyval リソースおよび情報
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - interagent/http-api-design: HTTP API design guide extracted from work on the Heroku Platform API
GitHub - AliSoftware/OHHTTPStubs: Stub your network requests easily! Test your apps with fake network data and custom response time, response code and headers!
REST API endpoints for repository webhooks - GitHub Docs
