タグ

関連タグで絞り込む (16)

タグの絞り込みを解除

RESTに関するikd9684のブックマーク (14)

  • HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様


    今日では HTTP(s) で API が公開されることは当たり前の時代ですが、エラーをアプリケーションにどう伝えるかは、個々の API の設計に依存していました。特に、HTTP ステータスコードは有限であり、元々持っている意味があるので、自由に使うことはできません。API はそのドメインごとにもっと複雑で細かなエラー情報があるはずで、それらはレスポンスボディに載せてアプリケーションに伝えることになりますが、その書式に規定は今までありませんでした。 HTTP API にて、アプリケーションにエラー情報を伝達するための︵レスポンスボディに載せられる︶標準的な形式が、RFC7807 Problem Details for HTTP APIsで定められています。適用例としては、以下のようになります。 HTTP/1.1 403 Forbidden Content-Type: application

  • yohei-y:weblog: REST の日本語リソース

    日本で REST がぜんぜん盛り上がっていないようなので、日本語で読める REST のリソースをまとめてみた。 東大市山氏による Roy Fielding の論文紹介。技術的な要素を理解したいけど RoyF のドク論を読むのは厳しい人にはお勧め。 http://kumiki.c.u-tokyo.ac.jp/~ichiyama/projects/reports/pdmwa 元論文はこれのようだ Principled Design of the Modern Web Architecture http://www.ics.uci.edu/~taylor/documents/2002-REST-TOIT.pdf 同氏による REST 版ショッピングカートの実装例。こちらも参考になる。 http://kumiki.c.u-tokyo.ac.jp/~ichiyama/projects/reports

    ikd9684
    ikd9684 2016/09/10
    リンク

  • マイクロソフト、「Excel REST API for Office 365」正式リリース。保存されたExcelのワークシートにAPIでアクセス可能


    マイクロソフト、﹁Excel REST API for Office 365﹂正式リリース。保存されたExcelのワークシートにAPIでアクセス可能 多くの企業で活用されているExcel。営業部門が各営業担当の進捗状況から売上げを予測するExcelシートを作成していたり、経理部門が経費の配賦をExcelのワークシートで管理してる、などという例も少なくないでしょう。 一般的にこうしたExcelで作り込まれた社内のアプリケーションを既存の業務アプリケーションに組み込むためには、いちどExcelで作り込まれたアプリケーションを解析し、あらためてプログラミング言語で組み立て直す必要がありました。 マイクロソフトが正式にリリースした﹁Excel REST API for Office 365﹂を用いると、OneDrive︵補足‥使えるのはOneDrive for Business︶に保存したExce
    マイクロソフト、「Excel REST API for Office 365」正式リリース。保存されたExcelのワークシートにAPIでアクセス可能

  • PHP Tips : kintone REST APIの認証設定について


    kintone REST APIを外部からリクエストするためは、 パスワード認証のためのヘッダーが必要となります。 この認証設定について、PHPでフォーム設計情報を取得するサンプルを交えて説明します。 kintone REST APIに最低限必要な情報は、サブドメインおよびユーザーのログイン名とパスワードです。 また、Basic認証を設定している場合は、Basic認証のログイン名とパスワードも必要となります。 サブドメインとは、普段アクセスしているcybozu.comのURL﹁https://sample.cybozu.com﹂の sample のことです。 このサブドメインは、サイボウズドットコム ストアのドメイン管理で変更できます。 kintone REST APIは、https://sample.cybozu.com/k/v1/(コマンド名).jsonというURLで実行します。 ちな
    PHP Tips : kintone REST APIの認証設定について

  • 「WebAPI 設計のベストプラクティス」に対する所感 - Qiita


    ﹁翻訳: WebAPI 設計のベストプラクティス﹂を読んで色々と思うところがあったので書きました。 上記の記事は訳文でありますので、正しくは﹁Best Practices for Designing a Pragmatic RESTful API﹂に対する所感と述べた方が良いのかもしれませんが、日本語で通して読めるようQiitaに投稿された訳文に対する所感として書いています。 以下では﹁翻訳: WebAPI 設計のベストプラクティス﹂並びに﹁Best Practices for Designing a Pragmatic RESTful API﹂は﹁当該記事﹂と表現します。 観点 当該記事では﹁○○とした方がよい﹂との意見に対してそうすべき理由が明らかになっていないか、もしくは表現が曖昧な場合が目立っていると感じました。設計は実装のようにプログラム言語仕様が制約を与えられないため、意図
    「WebAPI 設計のベストプラクティス」に対する所感 - Qiita

  • RESTful APIの記述標準化を目指す「Open API Initiative」をマイクロソフト、Google、IBMらが立ち上げ。Swaggerをベースに


    RESTful APIの記述標準化を目指す﹁Open APIInitiative﹂をマイクロソフト、Google、IBMらが立ち上げ。Swaggerをベースに10年以上前、XMLの登場に続いてXMLベースのAPIを記述する標準フォーマット﹁WSDL﹂が提唱されました。 WSDLにはAPIの仕様がマシンリーダブルな形で記述されており、APIを呼び出すためのプロトコルやデータフォーマットをあらかじめ知ることができます。WSDLを利用することで、APIをコールするためのコードを自動生成することが可能でした。 しかしXMLベースのAPIは期待されたほど普及せず、現在ではよりシンプルなRESTful APIが事実上の標準となっています。 そしてRESTful APIのためのWSDLとも言うべき、RESTful APIのインターフェイスを記述するための標準フォーマットを推進する団体﹁Open AP
    RESTful APIの記述標準化を目指す「Open API Initiative」をマイクロソフト、Google、IBMらが立ち上げ。Swaggerをベースに

  • RESTのベストプラクティス | POSTD


    現在ではREST APIはとても一般的な話題です。ほとんどすべてのWebアプリケーションの一部分となっています。シンプルで一貫性があり実際的なインターフェースは必須です。これは皆さんのAPIを他の人が使うことをとても容易にします。皆さんにとってはRESTの実践が日常的に感じられるかもしれませんが、RESTをあまり尊重しない人々もよく見かけます。これがRESTについて投稿するきっかけでした。 この記事にはRESTfulなAPIを設計する時に考慮すべきベストプラクティスがあります。 注意 : ここでのベストプラクティスは、私が過去の経験に基づいて良いと考える事例です。もし違う考えをお持ちであれば、お気軽にメールをくだされば意見交換できると思います。 APIのバージョンを示す APIのバージョンは必須であるべきです。これがあると時間が経ってAPIが変わっても影響を受けません。その方法の1つはUR
    RESTのベストプラクティス | POSTD
    ikd9684
    ikd9684 2015/05/27
    リンク

  • Rails で、Controller に定義されている action を一度に取得する方法はありますか？ - QA@IT


    平素よりQA＠ITをご利用いただき、誠にありがとうございます。QA＠ITは﹁質問や回答を﹃共有﹄し﹃編集﹄していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー﹂として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日︵金︶15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。QA＠ITの7年間で皆さまの知識
    Rails で、Controller に定義されている action を一度に取得する方法はありますか？ - QA@IT

  • WebAPIのステートレスなCSRF対策 - あめだま

    Jerseyのバージョン1.9.1で追加されたCSRFをステートレスに防ぐフィルタが興味深かったので、そのメモです。 CSRF対策の手法 通常、CSRF攻撃を防ぐにはトークンを使う方法があります。サーバがクライアントにトークンを発行して、クライアントは発行されたトークンをクエリパラメータなどの形でリクエストに付与します。サーバはトークンが付与されていないリクエストを実行しません。攻撃者は発行されたトークンを知らないため、リクエストを実行できないという寸法です。 CSRF対策とステート ただし、この方法ではトークンの取得〜リクエストの発行にステートができるため、WebAPIがステートフルになってしまうという問題があります。RESTベースのWebAPIはやはりステートレスに作りたいところです。 そこで、JerseyのCSRF対策フィルタはステートレスになるよう作られています。 JerseyのC

    WebAPIのステートレスなCSRF対策 - あめだま

  • なぜ html の form は PUT / DELETE をサポートしないのか？ - Block Rockin’ Codes

    注意 内容については一切保証しません。 ここでは、主に W3C ML での議論や各種仕様などに基づいて書いています。 ここに書かれていることが正しいかどうかは、自身で判断して下さい。 事実としておかしいところなどは、コメントでどんどん指摘して下さい。遠慮はいりません。 ただし、このエントリでは「form が PUT/DELETE をサポートするべきかどうか？」の議論はしません。 「REST の是非」や「PUT/DELETE の意義」についても議論する気はありません。 ここでやっているのは、あくまでもどういった議論の末現状があるのかの調査です。 そうした意見がある場合は、 W3C などに投稿するのが最も有益だと思います。 History 2014/03/29: 公開 2014/03/29: XForm と XHTML の関係を明確化(thanx koichik) 2014/03/29: HT

  • Kazuho@Cybozu Labs: REST におけるトランザクションについて (Re: Web を支える技術)


    といいつつ、ひとつだけ理解できないというか、納得できないところが。トランザクションのところがなんだかRESTっぽくないのがすごく気になる Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESSプラスシリーズ)(山本 陽平) - ただのにっき(2010-04-23) ﹁Web を支える技術﹂は自分もとてもいい本だと思う (教科書としてすばらしいし復習用としても読みやすいのでイイ) のですが、トランザクションの所だけは分かりづらいなと感じました。その原因は、atomic transaction で解決できる課題を例として使っているという点と、トランザクションと更新クエリのレイヤ分割がされていない、という2つの点によるものではないでしょうか。 HTTP 上でトランザクションを表現する必要があるケースのほとんどは、atomic transaction ではなく
    ikd9684
    ikd9684 2013/10/30
    リンク

  • 世の中のHTML5アプリケーションが糞だから、俺が「初期化」の作り方を教えてやんよ - mizchi's blog


    2chまとめみたいなタイトルにしてみた。(してみたかった) HTML5のアーキテクチャと初期化とキャッシュの考え方が、﹁ウェブエンジニア﹂は本当に出来てない。 とくにソシャゲをウェブビューに貼ってスマホ対応しました系。本当にダメ。 じゃあどうするか？基本的に﹁初期化﹂の考え方を直せばどうにかなる。 (この記事はBackboneを使うときに考えてることだけど、他でも一緒だと思う) 前提 シングルページアプリケーション セマンティクスやSEOは考慮しない 基本哲学 共通モデルの初期化を徹底的に行う サーバーにリクエストを投げるのは最小限 クライアントでサーバーモデルのキャッシュを作り、更新が期待されるまで再取得しない 理由 いくらDOMの最適化したところでUXに影響が大きいのはサーバーリクエスト(200~2000ms)で、プログラミング段階で辛さがあつまるのは非同期処理の部分。 プログラマとし
    世の中のHTML5アプリケーションが糞だから、俺が「初期化」の作り方を教えてやんよ - mizchi's blog

  • IBM Developer

    IBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.

    IBM Developer

  • yohei-y:weblog: REST 入門


    日本語の REST のリソース集を以前作ったのだが、 日本語では一般人向けの解説がない。 sheepman氏の REST のページはすばらしいんだけど、多少わかっている人向けだ。 市山氏のプレゼン資料は RoyF の論文を詳しく解説していてよいのだけれど、いかんせんアカデミックすぎる。 技術的な要素も抑えつつ、入門者にもわかりやすい解説はないものかと探していたのだが、みつからない。 英語の文書を訳すことも考えたんだけど、あまりよいものが見つからない。 で、結局自分で書くことにした。 最初はひとつのポストで済ませるつもりだったんだけど、書き始めたら長くなってしまったので、複数のポストに分けることにした。 えらそうなことを書いたが、内容は﹁ないよりマシ﹂といったレベルだろう。 前書きが長くなったけど(ここから始まりです。ですます調なのは入門記事だから)、 この記事(から始まる一連のポスト)は
  • 1

お知らせ

もっと読む

公式Twitter

  • @HatenaBookmark

    リリース、障害情報などのサービスのお知らせ

  • @hatebu

    最新の人気エントリーの配信

はてなブックマーク

公式Twitter

はてなのサービス

  • App Storeからダウンロード
  • Google Playで手に入れよう
Copyright © 2005-2024 Hatena. All Rights Reserved.