タグ

RESTに関するclavierのブックマーク (100)

  • HATEOASって何だ? - uehaj's blog

    Grails 2.3のRest機能のドキュメントを読んでいたら、拡張の一つとして「8.1.7 Hypermedia as the Engine of Application State」というのが書いてあって、調べると面白かったので、この資料(REST: From GET to HATEOAS)を読んだだけでの、私の理解する限りのメモを記しておきます。 一言でいうと、HATEOASとは、Restfulパターンを拡張するアーキテクチャパターンで、Restful原則に対する追加的な制約。どういうものかというと、HTMLアプリの画面遷移を抽象化した、状態遷移を表現するRestful API(=Restful WebアプリのWebインターフェース)を設計するための具体的な方法論になってる。 もちろんGrailsに特化したものではなく、Restと同じレベルのWebアプリケーション一般概念でありRes

    HATEOASって何だ? - uehaj's blog
  • REST: From GET to HATEOAS

    Presentation I gave at JPoint Meetingpoint (in a slight different version) and GotoCon Amsterdam 2012. How to get your API or service from using the basic REST principles such as verbs and resources to a complete RESTful service that fully supports "Hypermedia as the engine of application state" (HATEOAS). More info at www.smartjava.orgRead less

    REST: From GET to HATEOAS
  • RESTful searching in Rails · The Business of the Web

    Making money on the web, one customer at a time © 2019 Over and over again I see people asking about how to do a search the "RESTful way" with Rails, and every time I do I just shake my head and wonder why we sometimes get so caught up in how we do something that it keeps from actually doing it. So, with that introduction, I want to present to you a really simple implementation of the most basic t

  • 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 ではなく

  • RestfuseによるREST API自動試験まとめ(その1) - Taste of Tech Topics

    こんにちは、Web系エンジニアのナカガワです。 皆さん、REST APIのテストはどのようなツールを使っていますか? 私はJUnitでテストが書ける「Restfuse」を使っています。 今回、実プロジェクトでRestfuse + Jenkinsで定期的にREST APIをテストする仕組みを構築したため、このあたりのノウハウをまとめて書きたいと思います。 REST APIテスト自動化のゴール ゴールは以下の二つです。 (1) APサーバ上で動作しているWebアプリケーションに対し、自動でREST APIテストを実施する。 (2) Jenkinsを用いてCIを実施可能にする。 まず今回は、前者のREST APIテストを実施するところまで紹介します。 Restfuseを使って、REST APIをJUnit上でテスト可能に! 先にも書きましたが、私が使ったのはRestfuseというツールです。 R

    RestfuseによるREST API自動試験まとめ(その1) - Taste of Tech Topics
  • はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知

    はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28

    はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
  • REST Hooks

    Reduce your REST API server load by 66x REST Hooks are a lightweight subscription layer on top of your existing REST API. Start Coding or try a demo app What are REST Hooks? REST Hooks itself is not a specification, it is a collection of patterns that treat webhooks like subscriptions. These subscriptions are manipulated via a REST API just like any other resource. That's it. Really. Read the docs

  • [Java] jersey-clientでHTTPアクセス | ルクサエンジニアのブログ

  • あらゆるRESTのテストが出来るWEB開発者用Chromeアプリ「Postman」:phpspot開発日誌

    Postman あらゆるRESTのテストが出来るWEB開発者用Chromeアプリ「Postman」。 通常のHTTP、Basic認証、ダイジェスト認証、OAuth等のテスト用クライアントとして活用できます。 HTTPであればGET、POST等のメソッドを選んで、任意のデータを送信することが可能。 返却値はHTMLでもJSONでもハイライトして見やすく表示してくれます。レスポンスBodyだけではなくヘッダーなんかも表示することができます。 Chromeアプリなのでとりあえず追加しておくだけでもしておくといいかも デザインがBootstrapベースでカッコよく使いやすいのも特徴 関連エントリ POSTやファイルアップロード等がPHPから簡単に行えるHTTPライブラリ「Unirest」

  • REST の欠点は何か

    Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。このでは、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

    REST の欠点は何か
  • RailsにおけるRESTfulなURL設計勉強会 メモ #sendagayarb - 130単位

    zusaar.com -&nbspzusaar リソースおよび情報 参加してきました。 以下、粒度にばらつきありますが、気になった点のメモです。ほぼ引用ですが、意図と違う表現になってしまっていたらすみません。 RESTful APIとしてのRailsとクライアントとしてのJavaScript (@ppworks) no title RESTfulの指向で考えると統一されたインターフェースで、URLを見ただけで何するかわかるのが良い JSはassetsのほうに統一しアクションごとに処理が書けるjQuery-Routerなどを使うと良いのでは RailsはだんだんAPI化していくのではないか 通常のHTTPリクエストと非同期HTTPリクエストを同じ統一インターフェースであるRESTfulな設計で管理すると一貫性が出て開発効率の向上につながる リソースモデリングパターンの提案 (@tkawa)

  • Charming Python: Functional programming in Python, Part 3

    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.

    Charming Python: Functional programming in Python, Part 3
  • iOSアプリで必要なサーバサイドの機能をまとめて提供!·Helios MOONGIFT

    Heliosはプッシュ、アプリ内課金、Passbookなどのデータを一元管理できるiOS向けサーバソフトウェアです。 iOSではアプリ単体を作って終わりというものも多いですが、サーバサイドとのやり取りするアプリも少なくありません。そうした情報のやり取りを一元的に提供してくれる専用サーバがHeliosです。 データがないのですが、これはPassbook向けのデータ管理。 Pushもあります。 さらにアプリ内課金。 HeliosはデータをRESTfulなAPIで管理します。Rackアプリとして立てることも、SinatraやRailsの中に取り込んでシステムを提供することもできます。iOSアプリ開発時に用意してあると開発がスムーズに進みそうです。 HeliosはRuby製のオープンソース・ソフトウェア(MIT License)です。 MOONGIFTはこう見る iOSアプリ開発者にとってみればサ

    iOSアプリで必要なサーバサイドの機能をまとめて提供!·Helios MOONGIFT
  • 僕が考えたRuby on RailsとDojo toolkitで作るWebアプリのデザインパターン

    今年の前半、ある限定した範囲で使うツールを以下の構成で作ってました。 Ruby 1.9.3 Rails 3.2 Dojo toolkit 1.7 Railsで何かを作るのが久々だったこと、 Erlangで最初作ったものをRubyベースでPortingすること、という背景があったのですが、実際に僕がRubyベースで書き直したときの書き方が結構満足いくものだったので、それをここで紹介してみたいと思います。もちろん、ドメインモデルへの考え方、RESTfulなWebアプリケーションの作り方、MVCモデルの適用、などなど「Railsならこうするだろ」というものがありますが、 「 広く一般に言われているセオリーは一切気にせず自分が作りやすい組み方をする」 という至極自己中心的な考えを持って確立されたのが以下に説明することになります。 すっごく違和感を持つ人も多いと思いますが、「こんな作り方もできるんだ

  • WebPay: 開発者向けクレジットカード決済サービス

    ドメインウェブの設定が見つかりません 考えられる原因 ドメインウェブの設定がまだ行われていない。 ドメインウェブの設定がまだ反映されていない。(反映には数時間~24時間かかることがあります) ドメインウェブ・DNSの設定が誤っている。 アカウントが存在しない、契約が終了している、削除されている。

  • Web API Design(その5) - winplusの日記

    これApigee | Google Cloud Blogの勝手訳のつづき。 「クライアントがサポートするHTTPメソッドが制限されているとき」ですが、GETは冪等じゃなきゃいけないし、少なくともPOSTだろと思うのですが、GETしかできないクライアントを想定しているのかな。 例外的な振る舞いの取扱いのTips これまでのところ、ベースラインつまり標準的な振る舞いを取り扱ってきました。 ここでは、発生しうる例外のいくつかを調査するつもりです。Web APIのクライアントがいままで議論してきたことのすべてを取り扱うことができないときには、例外が発生します。たとえば、HTTPのエラーコードを横取りしてしまうクライアントがありますし、制限されたHTTPメソッドしかサポートしないクライアントもあるでしょう。 このような状況を取り扱うには、どんな方法があるしょうか?そして、特定のクライアントの制限のな

    Web API Design(その5) - winplusの日記
  • Web API Design(その4) - winplusの日記

    これApigee | Google Cloud Blogの勝手訳のつづき。 属性の名前をどうするか 直前のセクションでは、フォーマットについて述べました。複数のフォーマットをサポートし、JSONを既定のフォーマットとして動作することを推奨しました。 こんどは、レスポンスを返すときに何が起こるのかを述べましょう。 データ属性をもったオブジェクトがあります。属性にどのように名前をつければよいのでしょうか? 主要なAPIからのAPIレスポンスをいくつか挙げます。 Twitter "created_at": "Thu Nov 03 05:19;38 +0000 2011": Bing "DateTime": "2011-10-29T09:35:00Z" Foursquare "createdAt": 1320296464 それぞれに異なったコード変換をつかっています。TwitterのアプローチはR

    Web API Design(その4) - winplusの日記
  • JSON on HTTPやWeb APIを各言語でどうやって実装するのか

    HTTPでアクセスして、JSONを返すようなWebサーバを書きたいとする。 どんな言語を選ぶか。どんなミドルウェアを選ぶか。どんなライブラリを選ぶか。 たとえば、TIOBE Softwareが公表している「Programming Community Index(PCI)」という指標がある。人気のあるプログラミング言語の数値化。これを見ていて思ったのは、「多すぎだよね、プログラミング言語」ということ。これらのうち、どの言語を勉強し、どの言語をプロジェクトに採用すべきなのか。 その感触を得るために、 「同じ仕様のREST serviceを複数言語で実装したらいいんじゃね?」 と思った。いくつかの言語で実装を起こしてみている。 前提条件 大規模な開発を想定する。ユーザの規模が大規模。トランザクション数が大規模。そして、開発者が大規模。 実用的かつモダンな開発を想定する。プロジェクト毎のバージョン

    JSON on HTTPやWeb APIを各言語でどうやって実装するのか
  • Railsの誤解:CRUDはRESTじゃない! - 杉風呂2.0 - A Lifelog -

    以下はNick Sutterer氏が2010年10月28日に自身のブログに投稿した、"Rails Misapprehensions: CRUD is not REST! "の翻訳です。人の許可を得て掲載します。 Rails Misapprehensions: CRUD is not REST! http://nicksda.apotomo.de/2010/10/rails-misapprehensions-crud-is-not-rest/ RailsとRESTについて調べている間、二つのことがよくわかった。 RailsでRESTがどうなっているのか、他と比べて、明解で、基礎的で、「印刷された」解説を見つけにくい。数千のスクリーンキャストを見てきたが、この素晴らしいガイドが一つあるだけだった。 みんなCRUDとRESTを混同している とりわけ後者は僕を困らせたが、あるチームをコーチすると

    Railsの誤解:CRUDはRESTじゃない! - 杉風呂2.0 - A Lifelog -
  • RailsのURL設計を考えてみる(6) 設計の選択肢 - ぶろぐ。@はてな

    今回は直接Railsとは関係ないのですが、先日こういうページを見つけました。 http://redrata.com/restful-uri-design/ これは2009年に書かれたもののようですが、URL設計に関する重要な考え方がいろいろ書かれています。 その中に、このブログのシリーズの(4) スラッシュと「持っている」関係や(5) Railsのリソースパターンの前段階になるような“Choosing a URI schemes for resource hierarchies”という話があったので、かいつまんで紹介したいと思います。 リソースの階層に対して、どういうURLを設計するか? 前提として、設計するWebサイトには、conversation(会話)というリソースが複数あり、それぞれのリソースはユニークなIDで区別されるとします。(IDは数字とは限らない識別子) /conversa

    RailsのURL設計を考えてみる(6) 設計の選択肢 - ぶろぐ。@はてな