@saboyutaka 合同会社春秋 Tech Base Okinawa 2023
はじめにTIG DXユニット 1真野です。 RESTfullとかRESTishな方針でWebA PIの横断検索を設計する際にチーム内で方針について議論したやり取りの備忘記事です。 注意としてB2C向けなWeb APIを提供するというよりは、主に企業間または企業内部で使われるようなAPIの設計のバイアスがあります。LSUDs（Large Set of Unknown Developers）かSSKDs（Small Set of Known Developers）で言えば、確実にSSKDs脳で記事が書かれています。 REST API広く使われているため日本語記事も多数です。実践RESTful HTTP - InfoQ や、0からREST APIについて調べてみた など良さそうな記事が沢山でてくるの読むと良いでしょう。一般的な設計方法はやや古いですがWeb API: The Good Parts
この設計ガイドは、デベロッパーが、シンプルで整合性があり、使いやすいネットワーク API を設計するために役立ちます。また、ソケットベースの RPC API と HTTP ベースの REST API の設計を統合する場合にも役立ちます。 RPC API は、多くの場合、インターフェースとメソッドの観点から設計されています。これらが追加されるにつれ、デベロッパーが各メソッドを個別に学習する必要が生じるため、負荷が大きく混乱しやすい API サーフェスになる可能性があります。これによって、膨大な時間がかかり、エラーが発生しやすくなることは明白です。 REST のアーキテクチャ スタイルは、主に HTTP/1.1 で正常に動作するように設計されていますが、この問題への対処にも役立ちます。そのコア原則は、少数のメソッドを使用して操作可能な名前付きリソースを定義することです。リソースとメソッドはそれ
見てみると、たしかに Get 系の API だとしても POST を利用しているし、API の URL 設計に get_shared_link_file のようによく言われる REST っぽい設計は使っていなかった。 この方針は同意だ。自分は結構前に REST っぽい API を捨てることにした。だからといって REST API がダメだとかは思っていない。 一般ユーザが使う場合の API は REST API であるほうが慣れ親しんでいる場合が多いからだ。 AWS で利用されている HTTP API 仕様AWS の DynamoDB の Erlang/OTP ドライバーを書いているときに気づいたのだが、AWS の一部のサービスはかなり独特な API の仕様になっている。
なんだか珍しく、あおり気味のタイトルにしてしまいました。 最近読んだ以下の記事が大変おもしろかったので、今まで私の中で度々反芻していたものを文章としてまとめてみました。 gihyo.jp なぜ今GraphQLが騒がれているのか。ポストRESTが求められている理由、なぜポストRESTが求められなければいけないのか？ ポストRESTの登場によって私たちにとって何が嬉しくなるのか？ そのあたりを色々と触れていきたいと思います。 本文に入る前に ここでは、RESTと記載していものに、REST ful であることも含めています。RESTの推奨（規約ではない）に準拠して開発されたAPIをREST Fulと呼ぶのであって、そこにAPIとしての違いは無いためです。 どちらかと言えば、私の意識としてはパブリックなAPI、オープンデータ用のAPIであったり、KintoneやSANSAN、Salesforce、
このヘッダーは、指定した値と、サーバー上の最新の値が同じ場合 (ETag が一致する場合) は、Range ヘッダーで指定した部分的なデータを取得し、一致しなければデータ全体を取得しなおすといった場合に使用します。(Range ヘッダーと共に使用します。) 例えば、大きなデータを複数回に分割して何かの処理をおこなう場合などに、その途中でデータが変更されてしまった場合には、変更されたデータを再度取得しなおして評価したい場合に、このヘッダーが使えます。 なお、上記で、確認の結果、処理されなかった場合は、その内容に応じたステータス コード (HTTP の StatusCode) を返します。例えば、If-None-Match ヘッダーを使用したリクエストで、ETag が一致していて結果 (Response の Body) を返さなかった場合は、ステータス コード 304 (Not Modifie
HTTP Status Codes This page is created from HTTP status code information found at ietf.org and Wikipedia. Click on the category heading or the status code link to read more. 1xx Informational This class of status code indicates a provisional response, consisting only of the Status-Line and optional headers, and is terminated by an empty line. There are no required headers for this class of status
日本語の REST のリソース集を以前作ったのだが、 日本語では一般人向けの解説がない。 sheepman 氏の REST のページはすばらしいんだけど、多少わかっている人向けだ。 市山氏のプレゼン資料は RoyF の論文を詳しく解説していてよいのだけれど、いかんせんアカデミックすぎる。 技術的な要素も抑えつつ、入門者にもわかりやすい解説はないものかと探していたのだが、みつからない。 英語の文書を訳すことも考えたんだけど、あまりよいものが見つからない。 で、結局自分で書くことにした。 最初はひとつのポストで済ませるつもりだったんだけど、書き始めたら長くなってしまったので、複数のポストに分けることにした。 えらそうなことを書いたが、内容は「ないよりマシ」といったレベルだろう。 前書きが長くなったけど(ここから始まりです。ですます調なのは入門記事だから)、 この記事(から始まる一連のポスト)は
SOAP、WSDL、UDDIなどを基盤とするWebサービスの標準化を行ってきた団体WS-I（Web Services Interoperability Organization）が、2002年からの約8年間の活動に幕を下ろしたことを正式に発表しました（参考：WS-I Completes Web Services Interoperability Standards Work（pdf））。 WS-Iは、WS-*と総称されるWebサービスのさまざまなプロトコル策定に取り組んできましたが、複雑すぎるといった評判がつきまとい、また策定そのものにも予想以上の時間がかかったことなどで、当初の想定ほど普及に至りませんでした。 そのSOAPに代わり、ここ数年サービス間をつなぐAPIとして存在感が高まっているのがREST（Representational State Transfer）と呼ばれるアーキテクチ
_ エンタープライジーなREST オライリーから私が監訳（という作業を初めて経験したわけですが、それは別の物語）した、『JavaによるRESTfulシステム構築』という本が近々出ます。 JavaによるRESTfulシステム構築(Bill Burke) この本は、実にいろいろな面からおもしろい。おもしろいので、オライリーの編集の方に翻訳して出版する価値もあれば意義もあるとお勧めしたわけで、当然、読むことをお勧めします。 さて、何がおもしろいのか。一端は後書きに書いたけど、当然、書ききれない点や後書きに書いてもしょうがない点とかは省略しているので、そのあたりを含めて紹介します。 1. 著者がBill Burke これはおもしろい。というのは、BillはJBoss野郎なのだ。当然、CORBAからのORPC男。当然EJB。もちろんEJB3。 なぜ、そのBillが『JavaによるRESTfulシステ
JavaによるRESTfulシステム構築 作者: Bill Burke,arton,菅野良二出版社/メーカー: オライリージャパン発売日: 2010/08/23メディア: 大型本購入: 28人 クリック: 804回この商品を含むブログ (40件) を見る これ，本当にタイトル勿体無いなぁって思う本でした． いや，タイトルに偽りは無いんだけど，これだと REST に興味無い人は手に取らないだろうなぁと思って，それは凄く勿体無い内容なので，ホントみんな読むと良いと思う． 簡単に説明すると，Java で REST を扱うために JAX-RS という API があるんだけど( JSR311 )，そのエキスパートグループの一人であり，さらにその実装である RESTEasy の作者が書いている本です． で，この人は元々 SOAP とかのどちらかというと Fat な仕様大好きっこだったので，この本には色
GET /WebSite1/WebService.asmx/getHello?str=string HTTP/1.1 Host: localhost HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Content-Length: length <?xml version="1.0" encoding="utf-8"?> <string xmlns="http://tempuri.org/">string</string> RESTは、WebブラウザのAjaxや、クライアントアプリから使う場合もあるが、サーバ間のシステム連携でも使う。 RESTの最大の特徴は「WebブラウザにURLを入力すれば動作確認できる」事である。 Webブラウザで容易に動作確認ができるため、すでに存在しているサービスに対しては「まずはアクセスしてみて必要な情報
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く