RESTful#とは勉強会2はすごかった | いきあたりばったり
先月末にRESTful#とは勉強会2を開催してきました。 これがもう！！！！本当に良かった！！！！勉強になった！！！まだ興奮冷めやらぬ感じです。 勉強会1回目が終わり、得たRESTの知識を私はすぐ実践に生かすことが出来ました。 「これはURLとアクション考えるとControllerもう1個用意する？」なんて会話も出るようになり、レベルアップした感があります。 2回目はどうしようかなとぼんやりしていた時に見た このスライドが大変興味深くて、他にもSlideShareのREST関係も徘徊しましたが、これが一番鷲掴みされました！！！ （レベルが上がってからまた徘徊すると、他の難しいと感じたものにも鷲掴みされるのかもしれませんね。楽しみ。） 「これは皆読むべき！そしてちゃんと理解できるようになりたい！」と思い、「WEBを支える技術」を見返したところ、最後の5部が「WEBサービスの設計」でしたので、
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
- The RESTful cookbook
Welcome to the REST CookBook REST is hot! And REST is finally rediscovered by API programmers all over the world. But REST isn't always as easy as it seems on first look. Dealing with HATEOAS, Code on demand and uniform interfaces can be really tricky and many people will fall back to not-so-restful approaches when things are starting to become more difficult. But it doesn't need to be. Once you g
)
Volley + Gson + Generics = God! (Android で OAuth な Rest Api のクライアント作成) - ボクココ
Android アプリでよくあるパターンとしては Restful な Web API を呼んで、リストや詳細を表示などが挙げられる。こんなとき、JSONで通信しているのであれば、リクエストのパラメータを作り、レスポンスを解析するというコードを書く必要がある。これが例外処理やらnullチェックやらで何かと面倒。そう感じることが多かった。 最近、gsonとの出会いがあった。なるほど、これを使えばJSONをパースせずともGetter, Setter を持つモデルクラスを作ればそこに詰め込んでくれる優れものだ。だがもっとシンプルにできないだろうか。。 Gson と Generics の相性 Generics は型に縛られず共通処理を書けるようになるテクニックだ。これを使えば以下のようなシンプルなREST クライアントが作成できる。 色々書いて気づいたが、下記コードを見るだけだととてもわかりにくい。
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リク
RESTFul(リソース指向アーキテクチャ)について - In urban breeze
2014-05-06 RESTFul(リソース指向アーキテクチャ)について アーキテクチャ ROA(Resource Oriented Architecture)について。 次の本を参考に勉強してみた。参考図書 RESTful Webサービス ROAの基本 アプリケーションを動作と名詞(リソース)で考える。 リソースは特定のデータ、データの演算結果、状態、ユーザーアカウントなどである。 URIに動詞を含めてはならない。 リソースはHTTPメソッドを使用してのみ操作できる。 アドレス可能性 リソースはアドレス(URI)で一意に表現する。 1つのURIが複数のリソースを示してはいけない。 リソースを特定の言語や特定のフォーマットで取得したい場合は「Accept-Language」や「Accept」、または「Media-Type」を使用する。このようにリソースの表現方法が複数あ
ハイパーメディアAPIをめぐるREST主義者的危機
ソフトウェア開発者のEvan Cordell氏は数週間前のAPI-Craftメールリストで，ハイパーメディアのREST制約は一般的なWeb API要件とどのように違うのか，という議論の口火を切った。 "REST主義者的危機(RESTistential crisis)"と題した論議の中で氏は，長年の議論と実践によってRESTスタイル最大の秘密，ハイパーメディア制約が明確になり始めたことを指摘している。Webでも明らかなように，人間中心のインタラクションには完璧に対応しているが，その一方でプログラマブルなWeb API一般においては，有用性に対する懸念がWeb APIコミュニティの中で増しつつあるようなのだ。 RESTに関する説明，ドメイン特有のWeb APIに適用した場合のハイパーメディアの制限，といった話題から始まった今回の議論では，新たなアーキテクチャスタイルの必要性の検討や，RESTを
RESTful Meetup vol.3 を開催しました #RWABookja - ぶろぐ。@はてな
4/12(土)の夜に『RESTful Meetup vol.3』を開催しました。 RESTful Meetup vol.3 - Sendagaya.rb | Doorkeeper 昨年の記事の通り『RESTful Web APIs』の読書会を月2回ペースで開催してきましたが、その後、著者のMike Amundsen(@mamund)さんから、ワークショップのために東京へ行くという知らせがあったので、これはイベントをやるしかない！ということで企画しました。 vol.3ということで、実は過去2回開催しています。そのときは『RailsにおけるRESTfulなURL設計勉強会』というタイトルで、かなりターゲットを絞っていたのですが、今回は「REST」「Web API」というかなり広いテーマにしました。このことでRuby/Railsに限らず多様な言語の人に集まってもらえたのがとてもよかったです。 ビ
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 とかからどうやって引っこ抜
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
