タグ

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

  • メッセージングアプリ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スタイルからRESTを学ぼう

    Hypermedia: The Missing Element to Building Adaptable Web APIs in RailsToru Kawamura

    RESTful #とは RailsスタイルからRESTを学ぼう
    t-wada
    t-wada 2014/11/01
    REST について初歩から分かりやすく説明している資料
  • 社内システムの構造と設計、実装のはなし(下書きバージョン)

    番用はこちら http://www.slideshare.net/tagomoris/devsumi2014-tagomorisRead less

    社内システムの構造と設計、実装のはなし(下書きバージョン)
    t-wada
    t-wada 2014/07/18
    モリスさんのデブサミ講演、下書き資料の方が字が多めで単体で読みやすいな。改めて良い講演/資料だ。
  • The Netflix Dynamic Scripting Platform

    by Sangeeta Narayanan Over the past couple of years, we have optimized the Netflix API with a view towards improving performance and increasing agility. In doing so, the API has evolved from a provider of RESTful web services to a platform that distributes development and deployment of new functionality across various teams within Netflix. At the core of the redesign is a Dynamic Scripting Platfor

    The Netflix Dynamic Scripting Platform
    t-wada
    t-wada 2014/06/30
    なるほどこれは確かに発想としては Web API 界のストアドプロシージャだなぁ
  • HerokuのAPIデザイン

    Herokuが自ら実践しているAPIデザインガイドをGithubに公開した. “HTTP API Design Guide” このガイドは些細なデザイン上の議論を避けて,ビジネスロジックに集中すること目的としている.Heroku特有なものではなく,一般にも十分適用できる知見となっている. 最近は,モバイル向けにAPIをつくることも多いため,勉強もかねて抄訳した.なお内容は,HTTP+JSONのAPIについて基的な知識があることが前提となっている. 適切なステータスコードを返す それぞれのレスポンスは適切なHTTPステータスコード返すこと.例えば,“成功"を示すステータスコードは以下に従う. 200: GETやDELETE,PATCHリクエストが成功し,同時に処理が完了した場合 201: POSTリクエストが成功し,同時に処理が完了した場合 202: POSTやDELETE,PATCHリク

    t-wada
    t-wada 2014/06/05
    Heroku が出した Web API 設計ガイド “HTTP API Design Guide” の抄訳
  • Microsoft Learn: Build skills that open doors in your career

    Microsoft Learn. Spark possibility. Build skills that open doors. See all you can do with documentation, hands-on training, and certifications to help you get the most from Microsoft products. Learn by doing Gain the skills you can apply to everyday situations through hands-on training personalized to your needs, at your own pace or with our global network of learning partners. Take training Find

    Microsoft Learn: Build skills that open doors in your career
    t-wada
    t-wada 2014/04/20
    内部のデータと外部のデータ、過去と現在と未来。違いと特性について
  • RESTful Meetup vol.3 を開催しました #RWABookja - ぶろぐ。@はてな

    4/12(土)の夜に『RESTful Meetup vol.3』を開催しました。 RESTful Meetup vol.3 - Sendagaya.rb | Doorkeeper 昨年の記事の通り『RESTful Web APIs』の読書会を月2回ペースで開催してきましたが、その後、著者のMike Amundsen(@mamund)さんから、ワークショップのために東京へ行くという知らせがあったので、これはイベントをやるしかない!ということで企画しました。 vol.3ということで、実は過去2回開催しています。そのときは『RailsにおけるRESTfulなURL設計勉強会』というタイトルで、かなりターゲットを絞っていたのですが、今回は「REST」「Web API」というかなり広いテーマにしました。このことでRuby/Railsに限らず多様な言語の人に集まってもらえたのがとてもよかったです。 ビ

    RESTful Meetup vol.3 を開催しました #RWABookja - ぶろぐ。@はてな
    t-wada
    t-wada 2014/04/17
    とても濃いイベントでした。登壇させて頂いて光栄でした!
  • BEAR.Sunday

    BEAR.Sunday is a resource orientated framework with a REST centered architecture, implementing Dependency Injection and Aspect Orientated Programming' at its core. Learn more »

    t-wada
    t-wada 2014/04/12
    REST の制約/思想をアプリケーション内部のアーキテクチャにまで適用した野心的なフレームワーク
  • Ruby RoguesメンバとiOSエンジニアのAPI議論 - ワザノバ | wazanova

    http://rubyrogues.com/147-rr-apis-that-dont-suck-with-michele-titolo/ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約4時間前 iOSエンジニアのMichele Titoloは、Objective-Cのディペンデンシーを管理するCocoaPodsのプロジェクトで知られてますが、モバイルエンジニアの立場からAPIを利用して開発するポイントについても、自らのブログでまとめています。 1) Follow Conventions はじめてのことにトライするときは先駆者の知恵に従うほうが、クオリティの高いものをつくれるので、conventionに従うのがよい。そのほうがデバッグもしやすい。自分でAPIのルールを定義する必要が生じた場合は、一貫性を維持し

    t-wada
    t-wada 2014/03/20
    API 設計についての議論。特に Michele Titolo が挙げている四つのポイントは素晴らしい。
  • 拡張可能なWeb APIの設計原則と、バージョン番号を使う理由について

    APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sightにはブコメしたのですが、Rebuild: 35: You Don't Need API Version 2 (Kenn Ejima)でも件に言及があったようなので、少し一般論を書いておきたいと思います。 ■Web APIの設計原則について そもそも、良いAPIとはどのような特性をもつものでしょうか? 一般的に、以下の2点が挙げられると思います。 拡張が容易である 拡張時に後方互換性を破壊しない ウェブの場合は、これに加え、 スケーラブルである HTTPに起因する問題に上手に対処できる ことが求められます。 前2者はウェブに限らない要件です。これを満たす設計手法としては、 リクエストおよびレスポンスのパラメータを拡張可能に 互換性を壊す拡張が必要な場合は、関数名を変える 古い関数は従来と同じ機能を

    t-wada
    t-wada 2014/03/12
    kazuho さん semantic versioning にも言及していてさすがだ
  • EVOLVE`13 Keynote: Scrambled Eggs

    A scrambled talk on some of the major issues I am working on at Adobe, including HTTPbis, DNT, advice on the REST architectural style and API versioning, software evolvability, and a sneak peek at a potential feature for Adobe AEM (CQ) to support continuous deployment.Read less

    EVOLVE`13 Keynote: Scrambled Eggs
    t-wada
    t-wada 2013/09/09
    RoyF の先日の講演資料。31ページに “What is the best practice for versioning a REST API ? => DON'T" とある。"REST is software engineering on the scale of DECADES" "REST is designed primarily to improve EVOLVABILITY"
  • CROSS 2013レポート(2) - mad-pの日記

    CROSS 2013レポートパート2です。次世代Webセッションのメモ。 CROSS 2013 間違いや発言意図と違う表現だ、などということがあると思います。ご指摘いただければ幸いです。 次世代Webセッション前半〜プロトコル編 http://www.cross-party.com/programs/?p=138 http://www.ustream.tv/recorded/28598269 司会 Jackさん(@Jxck_) 以下J 大津さん(@jovi0608) SPDY関連 以下jovi 小松さん(@komasshu) Websockets 以下koma 清水さん(@kazubu) HTTP/2.0 以下kazubu HTTP2 2012/11最初のドラフト。絶賛議論中 どんなところが問題? kazubu: 前回のIETFの続きのトピック。crimeアタックに関して圧縮回り見直しとか

    CROSS 2013レポート(2) - mad-pの日記
    t-wada
    t-wada 2013/02/04
    次世代 Web セッションの詳細なメモ
  • 信頼できるメッセージングは、不要。

    原文(投稿日:2010/06/18)へのリンク SOA やWeb サービスで一般的に容認された考え方は、信頼できるメッセージングの必要性である。信頼性のあるメッセージングとは、送信アプリケーションによって送られたメッセージは、もう一方で確かに、受信されそして1回のみ受信される、ことを保証する。RESTに対する最も共通の拒絶理由の1つは、RESTが信頼できるメッセージングを提供していないことである。Stefan Tilkov 氏が次のように書いている:「RESTful HTTPは、WS-ReliableMessaging と同等ではない、としばしば指摘され、このために、信頼性が争点(これは、相当変わってしまう。あらゆるシステムがビジネス シナリオによって、どのような関連性でも持つので)となる分野では、使えない、と多くの人々が結論している」[1]。もちろん、Tilkov氏は、これに賛成しないで

    信頼できるメッセージングは、不要。
    t-wada
    t-wada 2010/07/14
    重要なトピックの良エントリだと思う。翻訳が少しわかりにくいのが残念。
  • O'Reilly Media - Technology and Business Training

    More than 5,000 companies count on our digital courses and more to guide their teams through the tools and technologies that drive business outcomes. We can help yours too. New AI policy for O’Reilly authors and talent O’Reilly president Laura Baldwin shares the company’s ethical approach to leveraging GenAI tools and ensuring O’Reilly experts are compensated for their work. See it now It’s time t

    O'Reilly Media - Technology and Business Training
  • 1