なぜポストREST APIが求められるのか？ REST APIがカバーできない2つの要因とその対策 - Morning Girl
なんだか珍しく、あおり気味のタイトルにしてしまいました。 最近読んだ以下の記事が大変おもしろかったので、今まで私の中で度々反芻していたものを文章としてまとめてみました。 gihyo.jp なぜ今GraphQLが騒がれているのか。ポストRESTが求められている理由、なぜポストRESTが求められなければいけないのか？ ポストRESTの登場によって私たちにとって何が嬉しくなるのか？ そのあたりを色々と触れていきたいと思います。 本文に入る前に ここでは、RESTと記載していものに、REST ful であることも含めています。RESTの推奨（規約ではない）に準拠して開発されたAPIをREST Fulと呼ぶのであって、そこにAPIとしての違いは無いためです。 どちらかと言えば、私の意識としてはパブリックなAPI、オープンデータ用のAPIであったり、KintoneやSANSAN、Salesforce、
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
REST API アクセス時のエラーハンドリングについて - Smartphone App - Mobage Developers Documentation Center
詳しくは OpenSocial RESTful Protocol Specification v0.9 - 13. HTTP Status Codes も参考にして下さい。 エラー時の HTTP レスポンス エラー時に JSON 形式でエラー内容を返します。各サンプルを参考にして下さい。 TextData API で TextDataGroup コレクションの一覧取得を Proxy モードで行った場合リクエスト GET http://sb.sp.app.mbga.jp/api/restful/v1/textdata/@app/@all?format=json Accept-Encoding: gzip Authorization: OAuth realm="", oauth_consumer_key="XXXXXXXXXX", oauth_nonce="YYYYYYYY", oauth_s
Representational State Transfer - Wikipedia
この記事には独自研究が含まれているおそれがあります。問題箇所を検証し出典を追加して、記事の改善にご協力ください。議論はノートを参照してください。（2023年11月） Representational State Transfer (REST、レスト[1][2][3][4]) は、ウェブAPI（ウェブアプリケーションプログラミングインタフェース）の定義に使用されるアーキテクチャスタイル（共通仕様）[5]であり、同時にウェブのような分散ハイパーメディアシステムのためのソフトウェアアーキテクチャのスタイルのひとつでもある。この語はHTTPプロトコル規格の主要著者の一人であるロイ・フィールディング（英語版）がウェブについて書いた2000年の博士論文で初めて現れ、ネットワーキングコミュニティの中ですぐに広く使われることになった。 RESTは、初めはアーキテクチャの原則と制約の集まり（後述）を指してい
プラットフォームとしてのWeb 2.0とRESTの関係
前回，REST（REpresentational State Transfer）アーキテクチャ・スタイルに準拠した，新しい軽量なWebサービスが増えてきたことについて触れました。アーキテクチャ・スタイルとは，情報システムのプロトコルやデータ構造（情報構造）の基本的性質を規定する“制約の束”のようなものです。今回は，このRESTについてもう少し説明しましょう。 RESTを既定する制約を挙げると以下のようになります。 (1)クライアント/サーバー型 (2)ステートレス（Stateless） (3)キャッシュを許可 (4)統一インターフェース（Uniform Interface） (5)階層化システム（Layered System） (6)コード・オン・デマンド（Code-on-Demand） (1)は，WebブラウザとWebサーバーで構成される，クライアント/サーバー型のネットワーク・アーキテ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
