http://blog.rakugakibox.net/entry/2014/11/23/java_spring_boot_rest
RESTful API の設計のキホン
2016/10/12 社内勉強会で使ったスライドを社外向けに一部加筆訂正したもの
HTTPステータスコードを適切に選ぶためのフローチャート : 難しく考えるのをやめよう | POSTD
HTTPステータスコードを返すというのはとても単純なことです。ページがレンダリングできた？よし、それなら 200 を返しましょう。ページが存在しない？それなら 404 です。他のページにユーザをリダイレクトしたい？ 302 、あるいは 301 かもしれません。 I like to imagine that HTTP status codes are like CB 10 codes. "Breaker breaker, this is White Chocolate Thunder. We've got a 200 OK here." — Aaron Patterson (@tenderlove) 2015, 10月 7 訳：HTTPのステータスコードのことは、市民ラジオの10コードみたいなものだと考えるのが好きです。「ブレーカー、ブレーカー、こちらホワイト・チョコレート・サンダー。200
PUT か POST か PATCH か？ - Qiita
CRUDの操作をRESTで表現すると一対一で対応していないことに気づきます。RはGET、DはDELETEと考えておいて良さそうですが、CとUはPUT、POST、PATCHの3つの選択肢があり、APIを設計していると迷います。整理するためにまとめておきたいと思います。 下記の資料を参考にしました。 http - PUT vs POST in REST - Stack Overflow When to use PUT or POST | - The RESTful cookbook GitHub API v3 基本的な考え方 PUT: リソースの作成、リソースの置換 POST: リソースの作成 PATCH: リソースの部分置換 PUTはPOSTと違い、リソース名を指定して作成または更新をかけるメソッドです。PUT /articles/3421は新規作成かもしれませんし、更新かもしれません。PU
Drupal8でREST APIを使ってみる - Qiita
認証プロバイダーとCSRFトークン 認証プロバイダー 標準でCookieとベーシック認証、モジュールの追加でOAuthを利用できます。 ■Cookieを使う 従来のセッションを使った認証を利用します。 /user/login にPOSTリクエストを投げることでログイン状態にします。 リクエストのたびに認証を行った（セッションIDが登録されている）クッキーを送信する必要があります。 ■ベーシック認証を使う DrupalのユーザID/パスワードでベーシック認証を行うことが出来ます。 リクエストにAuthorizationヘッダーを付加して送信します。 ■OAuthを使う この記事では取扱いませんが、Simple OAuthモジュール(OAuth 2.0)、OAuthモジュール(OAuth 1.0)を導入すると利用できるようです。 この辺りもご参照ください。 Simple OAuth: toke
RESTful Web API 開発をささえる Garage (client 編) - クックパッド開発者ブログ
料理動画事業室の @yoshiori です。前に「RESTful Web API 開発をささえる Garage」で紹介した RESTful Web API を開発する Garage のクライアント側のライブラリを公開しました。この記事ではその使い方を紹介したいと思います。Garage の設計思想やサーバ側の実装については上記記事を御覧ください。 今回は簡単にクライアント側の挙動を知っていただくために pry を使って説明したいと思います。 アクセスするサーバは先程の記事で作成したアプリケーションを使用してみます。 サーバの準備 https://github.com/taiki45/garage-example の README にも書いてありますので簡単に進めたいと思います。 まずは下準備としてコードを github から clone してきて、ライブラリのインストールと DB のマイグレ
REST APIドキュメント作成ツールはapiary.ioが決定版かもしれない - Qiita
背景 APIドキュメントを書くのが楽になるツールまとめ - Qiita iodocsで便利なREST APIドキュメントを作成する - Qiita これまでずっとREST APIドキュメントをwiki上で管理していて、重たいページ上で特殊記法使ったり、スタイルの調整に時間を取られるのが辛かった。そこで良さげなドキュメントツールを色々調べてたんだけど、最終的にapiary.ioが一番良さそうという結論になってきた。 このサービスの主な特徴。 markdown記法でAPIドキュメントを記述できる ドキュメントの生成と同時にAPIのモックサーバを用意してくれる サインアップから5分くらいあればドキュメント公開できる。ドキュメントのホスト先を気にしなくてもいい。 特にドキュメントと一緒にモックを作ってくれるのは他にはないポイントでかなり便利。 使ってみる サインアップはGithubアカウントで h
アプリ向けのサーバーAPIは「REST」 or 「WebSocket」？
アプリとサーバー間のやりとりをREST APIかまたはWebSocketで実装するか迷ったときの覚書。 よくまとまっているサイト WebSockets versus REST? （上記サイトの日本語訳）WebSockets vs. REST? 今のところ「共存出来るんだから、それぞれの特性を理解して使い分けろ」に落ち着いている感じ。 WebSocketでやりとりするメッセージにルール付けして、RESTを表現しようとする動きもある。 SwaggerSocket Protocol · swagger-api/swaggersocket Wiki NginxはWebSocketをリバースプロキシ出来るし、ロードバランサとしても動作する。 NGINX as a WebSockets Proxy - NGINX ExpressJSとSocket.IOでセッションを共有出来る。 node.js - s
APIドキュメントを書くのが楽になるツールまとめ - Qiita
さいきんREST APIのドキュメントを書いていて、wiki使うのだるいし他に良い方法ないかな〜と調べてた時に見つけたツール群をまとめてみます。 追記: こちらも便利そうなので参考にどうぞ。 REST APIドキュメント作成ツールはapiary.ioが決定版かもしれない - Qiita swagger Swagger: A simple, open standard for describing REST APIs with JSON | Reverb for Developers デモ: Swagger UI ソースコード中にAPIの概要を書いておくと、それを元にドキュメントを自動生成してくれる。wikiやmarkdownで書くのと決定的な違いは、↓のようにドキュメント上のformからAPIコールを試すことができる点。 様々な言語のWAFに対応したライブラリも開発されてる。 Home ·
プログラミング初心者が中・上級者になるためには、GithubのリポジトリをWatchすればいいんじゃないかな - iakioの日記
よく、プログラミングを学ぶ方法として「まずは何か作りたいものを見つけて、、、」といったアドバイスを見かける。たしかに何かを作り上げることで学ぶことも多いのだけれど、どちらかというとそれは実装方法よりもデプロイだったりライブラリやツールの使い方といったところの方が大きいように感じる。 一方で、実装方法については、自分で問題を解決しているだけだとどうしても自分の考え方にとらわれてしまう。 プログラミングの上達のためにきっと一番大切なことは環境で、近くに良い師匠がいるのであれば様々な問題の解決方法を学ぶことができるだろう。 そうでない場合は、インターネット上でお手本を見つけるのが良いと思う。 あまり大きすぎず、ある程度活発なお気に入りのプロジェクトをGithubで見つけてWatchする。毎日届くNotificationをざっとで良いので目を通す。最初はほとんど意味がわからないだろうけどかまわない
RESTが日本で受け入れられていった頃の話( #mozaicfm の補足) - Kentaro Kuribayashi's blog
mozaic.fm第7話のRESTの話で、RESTが日本で広く受け入れられていった頃、というか、その端緒の頃の話が出ていて懐かしかったのだし、細部にやや不正確なところがあるのが気になったりもしたので、補足を書いておきますね。 まず、いわずとしれた@yoheiさんがRESTをまず知ったのが2003年とかそれぐらいの時期とおっしゃっていて、それから数年経ち、RESTがWebエンジニアに広く受け入れられていったのは、2007年末にリリースされ、resourcesという機能を取り入れたRails2からというのは、@t_wadaさんがおっしゃっている通り、事実だろうと思います。 また、Podcastの中では、主催のJxckさんが、それはそれと認めた上で、彼自身にとってはAjaxの登場が大きかったということを述べた上で、@yoheiさんの主催された第八回XML開発者の日での高橋征義さんとid:seco
あなたにWebSocketは必要ないかも | POSTD
(訳注：2015/8/4、いただいた翻訳フィードバックを元に記事を修正いたしました。) 本題に入る前に強調しておきます。WebSocketは優れた通信プロトコルです。実際私はこの RFC6455 を、 Fanout のサービスで使っている( Zurl や Pushpin といったパーツで採用しています。Fanoutではまた、 Primus （異なるリアルタイムフレームワーク間での通信を可能とするラッパー）を利用し、 XMPP-FTWインターフェース を介したWebSocket通信をサポートしています。 しかしながら私はこれまで、多くの広く普及しているアプリケーションにかなりの時間を費やし、おかげでRESTやメッセージングパターンについては多少なりとも理解が深まってきた今、実はWebSocketを実装した典型的なWebアプリケーション（もしくはWebSocketライクな抽象化レイヤ）の大部分
Creating a simple REST application with Silex.
general geek, web developer (LAMP), proud Linux user So you have come to the conclusion that, rather than having the code to update customer details and that little fix to convert the date from GMT to UTC should happen in once place rather than being copied into several pieces of code, a REST service is the answer. Perhaps you just think you should know how to create a REST service. Either way thi
GitHub - quirkey/sammy: Sammy is a tiny javascript framework built on top of jQuery, It's RESTful Evented Javascript.
Sammy http://sammyjs.org Description Sammy is a tiny javascript framework built on top of jQuery inspired by Ruby's Sinatra. Installation Download Sammy.js and install it in your public javascripts directory. Include it in your document AFTER jQuery. Usage Like Sinatra, a Sammy application revolves around 'routes'. Routes in Sammy are a little different, though. Not only can you define 'get' and '
YeomanでフロントエンドとREST APIサーバーを同時に開発する方法 - bathtimefish's blog
先月のHTML5など勉強会で、Yeoman超入門を発表したときに、Yeomanはフロントエンド開発専用にlocalhostサーバー立ち上げるからサーバーサイドとの同時開発はちょっと工夫がいるよね〜みたいな話題があって、参加されてたnode.jsに詳しい方からhttp-proxyつかってapiの部分リダイレクトかけたらいいよみたいな方法を教えてもらった。 なるほどそれは便利だなと思って実際書いてみたら手軽に使える感じにできたので書いておきます。ちなみに今週水曜日にGoogle Developers Liveに出演してYeomanのことを喋らせていただく機会に恵まれたので、その時の参照にも使えるかと思って。（ライブのスライドはこちら） Yeomanは $ grunt server で開発用のWebサーバーを起動することができる。デフォルトで http://localhost:9000/ 以降フ
Reviewing RESTful Web Apps
This document summarizes Takuto Wada's presentation on reviewing RESTful web apps. It discusses best practices for designing RESTful resources and representations, including using nouns instead of verbs in URLs, making URLs reflect the meaning of resources, and ensuring resources are connected through hypermedia links and forms. It also covers appropriate use of HTTP methods, status codes, and con
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
RESTfulとは
RESTful #とは RailsスタイルからRESTを学ぼう
WebAPIのこれまでとこれから
なぜ html の form は PUT / DELETE をサポートしないのか？
