タグ

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

タグの絞り込みを解除

RESTに関するt-wadaのブックマーク (215)

  • GraphQLは何に向いているか - k0kubun's blog


    今年GitHubがGraphQL APIを正式公開したあたりから、GraphQLが去年とかに比べちょっと流行り始めたように感じる。idobataがGraphQL APIを公開したり、Kibelaも公開APIをGraphQLで作ることを宣言している。 利用者側からすると使えるインターフェースの中から必要なものを調べて使うだけなのであまり考えることはないのだが、自分がAPIを提供する立場になると話は変わってくる。REST APIとGraphQL APIはどちらかがもう一方のスーパーセットという風にはなっておらず、どちらかを選択すると何かを捨てることになるので、要件に応じてどちらを選ぶのが総合的に幸せなのか考える必要がある。 以前趣味でGitHub連携のあるサービスを作っており、それを最近GraphQL API v4を使うように移行し、そこでついでにそのサービスのGraphQL APIを書いてみ
    GraphQLは何に向いているか - k0kubun's blog
    t-wada
    t-wada 2017/09/12
    冷静な筆致でよくまとまっている
    リンク

  • ReactSPAをRailsに戻している話 - Speaker Deck

    All slide content and descriptions are owned by their creators.

    ReactSPAをRailsに戻している話 - Speaker Deck
    t-wada
    t-wada 2017/04/28
    「一画面で何回もリクエストを発生させがち、 N+1 問題が起こりがち」なのは RESTful API のつらみじゃなくて API 設計の誤り。オレオレ Flux 問題もあるので引き返すのは正しいと思う。
    リンク

  • ウェブを発明したティム・バーナーズ＝リー氏にチューリング賞


    30年近く前にワールドワイドウェブ︵WWW︶を発明したTim Berners-Lee氏が、コンピューティング業界最高の権威を持つ賞を受賞した。大成功を収めた同氏の発明であるWWWは現在、新しいモバイル技術の台頭という局面に差し掛かっている。 Association for Computing Machinery︵ACM︶は米国時間4月4日、Berners-Lee氏に2016年度A.M.チューリング賞を授与した。受賞者には賞金100万ドルに加えて、最高の栄誉が贈られる。この賞は、英国の研究者であるAlan Turing氏にちなんで命名されている。Turing氏は、第2次世界大戦中にドイツの暗号機﹁エニグマ﹂の暗号解読を支援し、コンピュータの基本設計の考案に貢献した人物。 Berners-Lee氏は、HTML︵Hypertext Markup Language︶とHTTP︵Hypertext
    ウェブを発明したティム・バーナーズ＝リー氏にチューリング賞
    t-wada
    t-wada 2017/04/05
    当然の受賞だと思う。本当にめでたい。
    リンク

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


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

  • RESTful API の設計のキホン

    2016/10/12 社内勉強会で使ったスライドを社外向けに一部加筆訂正したもの

    RESTful API の設計のキホン
    t-wada
    t-wada 2016/10/14
    よくまとまっている資料ですばらしい
    リンク

  • Microsoft REST APIガイドラインはRESTfulではない


    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が最近リリースされ、重要な変...
    Microsoft REST APIガイドラインはRESTfulではない
    t-wada
    t-wada 2016/08/05
    先日 MS が公開した「REST API設計ガイドライン」はただの HTTP API であって RESTful API とは呼べないと Roy Fielding 閣下がお怒りのようです (これを MS のさとうなおきさんが訳したのは懐が深いなとも思う)
    リンク

  • REST API設計ガイドライン


    Office Dev Center > REST API Design Guidelines https://dev.office.com/blogs/rest-api-design-guidelinesMicrosoftがAPIコミュニティに﹁REST API設計ガイドライン﹂(https://github.com/microsoft/api-guidelines/)を公開することを発表できて、嬉しく思います。 このガイドラインは、Microsoftの世界規模のクラウド サービスの設計、運用、稼働を行い、お客様やパートナーからの我々のAPIへのフィードバックに耳を傾けている、数百人のエンジニアの集合体験を集約した、複数年にわたる企業横断的な協力プロセスを象徴しています。我々は、MicrosoftのAPIチームが日常的に使うガイドラインを作成するために、API領域の業界のベスト プラクテ
    REST API設計ガイドライン
    t-wada
    t-wada 2016/08/05
    先日 Microsoft が GitHub で公開した包括的な設計ガイドライン「REST API設計ガイドライン」公開の背景について
    リンク

  • 綺麗なAPI速習会 - Qiita


    Wantedly Engineer blogに本速習会資料を閲覧向けに再編しました！ ぜひご覧いただけると幸いです！ 本記事は、綺麗なAPI速習会@Wantedlyの資料として作成されたものです。 同時にこちらのコードも参照してください。 マイクロサービス 流行りのマイクロサービス、何がいいのか 各々自由な言語やArchitectureでサービスを立てられる 障害の影響が部分的 変化に強い 個別デプロイ etc... マイクロサービス化をすすめるにあたり、やりとりは全てAPIで行う 内部のAPIであっても外部に公開できるようなクオリティのAPIを作成し、それを元にサービスを作っていくことが重要 APIGatewayとBFF API Gateway Pattern 公式サイトより ﹁見た目はモノリシック、実装はマイクロサービス﹂ 一箇所見に行けば全てのAPIを見つけられる 細かい権限管理も可
    綺麗なAPI速習会 - Qiita
    t-wada
    t-wada 2016/08/05
     APIGateway や BFF も視野に入れた RESTful な Web API の構成と設計方法について。とくにページネーションの API に関する設計が詳しく解説されている。すばらしい。

    ●web
    ●REST
      
    リンク

  • api-guidelines/Guidelines.md at master · microsoft/api-guidelines

    You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

    api-guidelines/Guidelines.md at master · microsoft/api-guidelines
    t-wada
    t-wada 2016/07/20
    Microsoft による RESTful Web API 設計のガイドライン。実践的なところまで踏み込んで網羅的に記されていて、とても良い。
    リンク

  • DHHはどのようにRailsのコントローラを書くのか | POSTD

    私たちの救世主DHH™は最近の Full Stack Radioのインタビュー で、 Basecamp の最新版で彼がどのようにRailsのコントローラを書いたかを説明しています。下記は、彼のすばらしい話を書き取ったものです。 これまでに思うようになってきたのは、「RESTの原則に従うには、どのタイミングで新たなコントローラを作るべきかを一度決めたら、ほぼ異例なくその原則を遵守するべきだ」ということです。いつだってその方がうまくいくんです。自分の作ったコントローラの状態を悔やむのは決まって、作ったコントローラの数が少なすぎた時です。多くの処理を任せようとしすぎてしまうんです。 そこでBasecamp 3では、ある程度理にかなったサブリソースがあれば、毎回コントローラを分割していきます。フィルタなどの場合ですね。例えば画面があって、それがある状態になっているとします。もしこれにいくつかのフィ

    DHHはどのようにRailsのコントローラを書くのか | POSTD
    t-wada
    t-wada 2016/03/19
    とてもよく分かる。私も DHH と同じコントローラの作り方をしています。
    リンク

  • RESTful#とは勉強会13 を開催しました #RESTudy - tkawaのはてぶろ。


    一昨年からだいたい月1回ぐらいのペースで、Webの基本的な仕組みを基礎から学ぶ﹁RESTful#とは勉強会﹂を開催しています。主催はshokolaさんで、私は進行役を担当しています。2月23日に開催したRESTful#とは勉強会13では、ヴァル研究所さんの協力のもと、駅すぱあとWebサービスをレビューするという企画をやりました。いろんな意見が出てとてもおもしろかったです。みなさんありがとうございました。 RESTful#とは勉強会13当日の内容とポイント RESTful#とは勉強会13ツイートまとめ ゲストとして来ていただいた@Keisuke69さんがブログ記事を書いておられたので、これは私も書かなければ、ということで感じたことを書いていきます。 keisuke69.hatenablog.jp 駅すぱあとWebサービスについて、当日思っていて言い忘れたこと トークンをURLのクエリパ
    RESTful#とは勉強会13 を開催しました #RESTudy - tkawaのはてぶろ。
    t-wada
    t-wada 2016/02/29
    "昨今のWeb APIを見てみると、セマンティクスがあまりに足りない" "OpenAPI(Swagger)、API Blueprint、RAMLなどは、近いところもありますが、RESTの制約である「自己記述的」を満たしていない"
    リンク

  • 例えば OSFA な API をやめる - @kyanny's blog

    OSFA == one-size-fits-all 単一の API で全てをカバーするのをやめたらどうか、ということ。 APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight @kenn 最近はRESTfulなエンドポイントは完全に後方互換なまま、クライアントごとにオーケストレーション層(radical versionin)を設けるという方向にシフトしようとしている。詳しくは http://t.co/zODm7mFr5B— Tatsuhiko Miyagawa (@miyagawa) February 28, 2014 この話のポイントとはちょっとずれてる && Podcast 聴いてないのですが。 Quipper プラットフォームで内部的に利用されている API も、 /v1 というパスの下にはえててごく一部のエンドポイントだけ /v2 がある、み

    例えば OSFA な API をやめる - @kyanny's blog
    t-wada
    t-wada 2015/09/18
    ジェネリックで汎用的な API だけで頑張るのではなく、クライアントアプリケーションに特化した一連の API を必要に応じて提供する設計について
    リンク

  • メッセージングアプリSync開発の舞台裏(iOS) - Qiita


    ビジネスシーンで使えるメッセージングサービスSyncをローンチしました。 その開発の舞台裏をiOSを中心に紹介します。開発のスケジュール、リソース、アプリの規模や進め方など参考になれば幸いです。 サービスについて Syncは社内・社外を問わずプロジェクトやビジネスコミュニケーションがより良い体験なることをゴールに開発しました。以下のURLよりご利用頂けます。 Web版 , Desktop版(OnlyOSX) , iPhone , Andorid アーキテクチャ サーバ 既存のWantedlyサーバに並列して、Syncのサービスをマイクロサービスアーキテクチャ風に構築しています。要素技術や構成はサービスの初期フェイズにおけるスピディーな開発とスモールな運用に適しているものを選定しています。 AccountServerが認証やユーザ情報管理を、APIServerが主要なデータのやり取りをRES
    メッセージングアプリSync開発の舞台裏(iOS) - Qiita
    t-wada
    t-wada 2015/09/10
    テクノロジスタックが今風で良い。あと Swift のコンパイルの遅さに対するソリューションが斜め上で面白い
    リンク

  • RESTful#とは勉強会で(Railsでの)ルーティングの考えだし方の話をしました - moroのブログ


    RESTful な設計って、ってマスタメンテ作るにはいいけどまともなサービス作れるの?という疑問に対して、結構やればアプリケーションできるので安心してください、という話をしました。 ﹁独自研究﹂セクション以外はだいたいふつうに経験したことです。﹁独自研究﹂セクションはたぶん、今流行りのオーケストレイションレイヤをどうするかというところになるのかな、と。APIといいつつ、HTMLを返す話ばかりですが、これはAPIとHTMLをあえて区別せずそれは単にリプレゼンテーションが違うだけです、という意図でした。 転職してから初の社外発表が前職オフィスでやるというのが面白かったです。永和メンバーも結構たくさん会えてよかった。来てくださった方、開催をアレンジしてくださった方、ありがとうございました。
    RESTful#とは勉強会で(Railsでの)ルーティングの考えだし方の話をしました - moroのブログ
    t-wada
    t-wada 2015/08/20
    RESTful な設計の基本を分かりやすく説明しているエントリ。さすが諸橋さん。
    リンク

  • WebAPIリクエスト仕様書としてcurlコマンドのご提案 - Qiita


    WebAPIの仕様を記述する方法はいくつかあると思う。 普通に日本語で記述する JSON Hyper-Schema、WADL、RAML、Swaggerなどを使う 仕様書の代わりにプログラムを書く HTTPメッセージそのものを記述しておく でも、文法にばらつきがあったり、読みにくかったり、ツールのセットアップが面倒だったり、どれもイマイチな所があって、手軽な方法が欲しいと思っていた。 何気なくcurlコマンドのオプションを調べていたら、﹁もうこれでAPIドキュメント扱いにしちゃえばいいんじゃね？﹂と思えてきたのでメモしておく。 curlコマンドのおさらい curlコマンドはlibcurlの付属コマンドで、最近のUnix系OSなら大抵最初から入っていると思う。コマンドの詳細はmanを読んでいただければ。 cURL - How To Use ︵マニュアルページ日本語訳︶ curlコマンドのオプシ
    WebAPIリクエスト仕様書としてcurlコマンドのご提案 - Qiita
    t-wada
    t-wada 2015/05/26
    面白い。すぐ試せる、実行可能なドキュメントという側面はとても良いと思う
    リンク

  • WebAPIでエラーをどう表現すべき？15のサービスを調査してみた - Qiita


    2017-01-05 追記 2016年3月にエラーの標準形式RFC7807﹁Problem Details for HTTP APIs﹂が提案され、今日現在proposed standard(標準化への提唱)となっています。こちらも是非ご覧ください。 RFC 7807 - Problem Details for HTTP APIs HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様 最近はREST APIを提供しているサービスが増えてきていますね！また公開されるAPIだけでなく、Microservicesなアーキテクチャを採用して、バックエンドがWeb APIで通信するケースも増えてきているように思います。 APIを使うときはあまり気にしたこともなかったですが、いざAPIを設計してみるとどんなインターフェイスがいいのか、どんな形式がいいのかといった疑問が次々と出てきます。
    WebAPIでエラーをどう表現すべき？15のサービスを調査してみた - Qiita
    t-wada
    t-wada 2015/05/26
    Web API のエラー表現 (エラー時のレスポンスボディ) を各社サービスがどのように設計しているかのまとめ。参考になる。実際の HTTP ステータスやヘッダがどうなっているのかも気になる。
    リンク

  • Rubyist Magazine - スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編)


    ﹃るびま﹄は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について ﹃Rubyist Magazine﹄、略して﹃るびま﹄は、Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0063 号 バックナンバー Rubyist Magazine 0063 号 Rubyist Magazine 0062 号Kaigi on Rails 特集号 RubyKaigi Takeout 2020 特集号 Rubyist Magazine 0061 号 Rubyist Magazine 0060 号 RubyKaigi 2019 直前特集号 Rubyist Magazine 0059 号 Rubyist
    Rubyist Magazine - スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編)
    t-wada
    t-wada 2015/05/11
    "API を呼び出すというメタファーが危うい (略) RPC と大差ありません。こういうイメージから離れましょう" REST とハイパーメディアについてきちんと説明。サーバからただ JSON を返している人にこそ読んで欲しい
    リンク

  • HTTPS 化する Web をどう考えるか - Block Rockin’ Codes

    Update 2015/5/8: 指摘頂いたタイポや誤訳などを更新しました。 2015/5/8: 構成を一部修正しました。 Intro 4/30 mozaiila のセキュリティブログに下記のようなエントリが投稿されました。 Deprecating Non-Secure HTTP | Mozilla Security Blog エントリはそこまで長くないので、ここに翻訳の全文を記載します。 そして、元エントリのライセンスである CC BY-SA 3.0 に則り、 本エントリも同じく CC BY-SA 3.0 とします。 Deprecating Non-Secure HTTP 原文: Deprecating Non-Secure HTTP 今日は、 non-secure な HTTP から、徐々に廃止していくという方針についてアナウンスします。 HTTPS が Web を前進させる手段である

    t-wada
    t-wada 2015/05/07
    牧歌的な時代の終わりなのかな
    リンク

  • 著者インタビュー | BOOKSCAN(ブックスキャン) 本・蔵書電子書籍化サービス - 大和印刷


    Profile 1975年生まれ。Web関連技術を中心に組込みソフトウェアからインフラまでの設計が主な仕事。2005年ごろからRESTという技術に着目し、ブログを中心に雑誌連載や監訳、講演で国内での啓蒙活動に従事。主な著書に﹃Webを支える技術﹄︵技術評論社︶。 共著・監修に﹃XML教科書﹄︵ソフトリサーチセンター︶、﹃RESTful Webサービス﹄︵オライリー・ジャパン︶などがある。 Tweet 1 2 全文 技術者なので、正しく技術が伝えられていないと﹁嫌﹂だと思う ﹃Webを支える技術﹄︵技術評論社︶﹃XML教科書﹄︵ソフトリサーチセンター︶﹃RESTful Webサービス﹄︵オライリー︶などの著者として有名な山本陽平さんは、メーカーのエンジニアとして開発を行いながらも、RESTの伝道師としての顔もお持ちです。そんな山本さんに、ソフトウエアを開発するきっかけについて、ネットや電子書
    著者インタビュー | BOOKSCAN(ブックスキャン) 本・蔵書電子書籍化サービス - 大和印刷
    t-wada
    t-wada 2015/04/03
    yohei さんのインタビューだ!!
    リンク

  • リソースの一部更新におけるURL設計 - Qiita


    概要 Webアプリケーションにて、リソースの一部更新を行う際、どのようにURL設計を行うとシンプルで美しいか︵本当はそこまで考えていなかったけど︶悩んでいたところ、 @t_wada さんから素敵な設計指針をご教示いただきました。 本記事はその内容に加えて、実際に自分で行ったこと、調べたこと、思った事など、まとめております。 あらすじ 数週間前にSIピラミッドからヒモなしバンジーを決めてWebの世界に飛び込んだ私は、小さな小さなWebアプリケーションをrails newから手探りで作っていました。 そんなとき、簡単なリソースの一部更新機能をどう実装したもんかなーと悩んでました。以下、当時︵といっても先週︶の超雑なぼやき。 リンクをクリックしてモデルの一部を変更するのはどうしたらいいんだろう。 例︶不参加をクリック -> 某カラムをtrueからfalseへ リクエストオブジェクトに対象カラムの
    リソースの一部更新におけるURL設計 - Qiita
    t-wada
    t-wada 2015/02/13
    流しの RESTful おじさん業の現場風景です
    リンク
  • 1 2 3 4 5 6 7 8 9 10 次のページ

お知らせ

もっと読む

公式Twitter

  • @HatenaBookmark

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

  • @hatebu

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

はてなブックマーク

公式Twitter

はてなのサービス

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