タグ

apiに関するyukio2005のブックマーク (47)

  • Google Wave - .mjtの日記復帰計画

    http://wave.google.com/ 重要なのはGoogle Waveには2つの基盤、XMPPとGoogle WaveのAPIの両方が有ることで、オープンなプロトコルとしてXMPPを使いつつ一種の囲い込みとしてGoogle WaveのAPIがある。 言うまでも無く我々はGoogleでは無いから、注目すべきはXMPPの方、つまりGoogle Wave Federation Protocolになる。 XMPPの重要性は多少注目されるようになるだろう。幸いなことにXMPP自体はそれほど理解が難しいものでもない。Google TalkではSkypeを駆逐できなかったが、これを機にうまい戦略が欲しいところ。 ただし、SMTPで儲けるよりもspamメールで儲ける方が手軽なように、Google Wave Federation Protocolの実装そのものを価値有るものにすることは困難な仕事

    Google Wave - .mjtの日記復帰計画
  • 「mixi始まって以来、最大の変化」――笠原社長に聞く「mixiアプリ」

    「mixi始まって以来、一番大きな変化だ」――ミクシィの笠原健治社長は、「mixiアプリ」に大きな期待を寄せている。 mixiアプリは、外部開発者がmixi向けアプリケーションを開発できるプラットフォームで、4月8日にオープンβ版をスタートした。8月に正式公開し、mixiユーザー全体に公開する予定だ(「mixiアプリ」8月に正式公開 販売収入8割を開発者に 広告収入も)。 笠原社長が期待するのは、mixi日記に並ぶような、強力なコミュニケーションアプリの登場だ。日記はmixiで最も使われている機能で、ユーザーがmixiにアクセスする最大の理由になっているが、日記が嫌いでmixiは使わない、という人もいる。 「日記は、20代女性には使いやすいかもしれないが、30代後半の男性や、家族同士、上司や部下などのコミュニケーション方法としてはベストではないかもしれない」――外部開発者の力を借り、それぞ

    「mixi始まって以来、最大の変化」――笠原社長に聞く「mixiアプリ」
  • APIアクセス権を委譲するプロトコル、OAuthを知る ― @IT

    クロスドメインでのデジタルアイデンティティを守る APIアクセス権を委譲するプロトコル、 OAuthを知る 作島 立樹 NRIパシフィック 2008/1/21 マッシュアップと呼ばれる仕組みで、既存のWebサービスが次々とつながり、新たなサービスが登場している。しかし、メールアドレスなど重要な個人情報が意図せずに「つながれてしまう」可能性もある。そこで登場したのがアクセス権の「委譲」を目的としたプロトコル、OAuthである。記事ではOAuthの仕組みとともに、なぜそれが登場したのかという背景にも触れる(編集部) マッシュアップの犠牲になるユーザーのアイデンティティ GETなどのHTTPメソッドをもちいてURLへリクエストする、いわゆる「RESTful」【注1】なWeb APIを使ったアプリケーション同士の交流は、いままさに隆盛を極めている。「マッシュアップ」と呼ばれているこのサービス形態

  • Ywcafe.net

    Ywcafe.net This Page Is Under Construction - Coming Soon! Why am I seeing this 'Under Construction' page? Related Searches: Contact Lens Dental Plans Credit Card Application find a tutor Top Smart Phones Trademark Free Notice Review our Privacy Policy Service Agreement Legal Notice Privacy Policy

  • プラットフォームとAPIについての素人臭い理解 - Thoughts and Notes from CA

    前回のエントリーで、クラウド・コンピューティングの1つのモデルとして、蓄積したデータベースそのものをAPIを用いて開放し、再利用・相互連携のしやすいアーキテクチャを作るという手法を紹介したが、このAPIという言葉は私のようなコードを書かない人間には実は結構わかりにくい。 OS(Operating System)とは、一口で言えばコンピューター上にあるファイル・システム、グラフィック・ユーザーインターフェイス・システム、タスク管理システム、などの各種システム・サービスの集合体のことである。ユーザーはユーザー・インターフェイスを介して、プログラマーはAPIを介して、それらのサービスとやり取りをする。 と紹介されている通り、元々はOS上で動くアプリケーションを開発する際の、OSの各種サービスを使用するためのOS側の受け口、という意味合いで使われていたようだが、時代と共にその意味がより拡張され、今

    プラットフォームとAPIについての素人臭い理解 - Thoughts and Notes from CA
  • オープンソースとクラウドコンピューティング雑感 - Thoughts and Notes from CA

    O'Reilly Radarの"Open Source and Cloud Computing"を読んだ。id:yomoyomoさんにどうやら先を越されてしまったが、稿についての最も質の高い日語情報である"オープンソースとクラウドコンピューティング"のブックマークがこんなちょびっとしかないというのも驚き。世間の関心はそんなに低いのだろうか? まぁ、それはさておき、自分の解釈も交えながら要点をかいつまむと以下のようにまとめることができる。 ソフトウェアの再配布、修正を認めるライセンス形態をとることにより、オープンソースは「多くの人が自由に使えば使うほど洗練されていく」という仕組みを作り、大きく繁栄をとげた 最近注目を浴びているクラウド・コンピューティングでは、オープンソース・ソフトウェアと蓄積されたデータベースを組み合わせ、コードではなく、サービスを提供するようになる クラウド・コンピュ

    オープンソースとクラウドコンピューティング雑感 - Thoughts and Notes from CA
  • Bridge Word

    This shop will be powered by Are you the store owner? Log in here

  • Facebook Platform で SNS 内アプリケーションを作ろう ~ Part 1 開発編 ~facebookのアプリケーション開発

    サイボウズはクラウドベースのグループウェアや業務改善サービスを軸に、社会のチームワーク向上を支援しています。

    Facebook Platform で SNS 内アプリケーションを作ろう ~ Part 1 開発編 ~facebookのアプリケーション開発
  • dfltweb1.onamae.com – このドメインはお名前.comで取得されています。

    このドメインは お名前.com から取得されました。 お名前.com は GMOインターネットグループ(株) が運営する国内シェアNo.1のドメイン登録サービスです。 ※表示価格は、全て税込です。 ※サービス品質維持のため、一時的に対象となる料金へ一定割合の「サービス維持調整費」を加算させていただきます。 ※1 「国内シェア」は、ICANN(インターネットのドメイン名などの資源を管理する非営利団体)の公表数値をもとに集計。gTLDが集計の対象。 日のドメイン登録業者(レジストラ)(「ICANNがレジストラとして認定した企業」一覧(InterNIC提供)内に「Japan」の記載があるもの)を対象。 レジストラ「GMO Internet Group, Inc. d/b/a Onamae.com」のシェア値を集計。 2023年10月時点の調査。

  • APIの公開はマーケティングに勝る?:インフラコモンズ今泉の多方面ブログ:オルタナティブ・ブログ

    株式会社インフラコモンズ代表取締役の今泉大輔が、現在進行形で取り組んでいるコンシューマ向けITサービス、バイオマス燃料取引の他、これまで関わってきたデータ経営、海外起業、イノベーション、再エネなどの話題について書いて行きます。 Twitterクライアントの繁盛ぶりを見ていると、APIを公開することがいかに偉大なことであるかをしみじみと考えさせられます。API公開は、おカネが一銭もかからないインストールベース拡大方策です(salesforce.comなんかもそうですね)。たしかドラッカーが「理想的なマーケティングとは販売を不要にすることだ」という意味のことを言っていたと記憶しています。API公開はまさにその具体例ですね。 ただまぁ、何でもかんでもAPIを公開すればいいというものではなく、APIによって得られるリソースがどれだけ価値があるかということが重要なのであって、例えば「質的に新しい」

    APIの公開はマーケティングに勝る?:インフラコモンズ今泉の多方面ブログ:オルタナティブ・ブログ
  • 次の1年 - 胃痛!イトマサのいわゆるチラシの裏:楽天ブログ

    2007.05.20 次の1年 カテゴリ:マーケティング 参照系APIが昨年普及した。 今年は、更新系APIが普及期に入る。 それとともに、APIデータストレージが次に来ると思う。 お気に入りの記事を「いいね!」で応援しよう いいね!0 シェアする Last updated 2007.05.21 02:14:50 コメント(0) | コメントを書く [マーケティング] カテゴリの最新記事 アメーバなう VS. GREEの芸能人コーナー 2009.12.09 クリエイターとプラットフォーム 2009.08.25 Googleのビジネスモデル 2009.08.04 もっと見る

    次の1年 - 胃痛!イトマサのいわゆるチラシの裏:楽天ブログ
  • Tomcatでダイジェスト認証を使う

    Tomcatには、基認証やダイジェスト認証などの、HTTPによるアクセス認証の機能が組み込まれています。Webアプリケーションに格的な認証を付けたい場合には、Tomcatのフォーム認証や自前で用意した認証機構などを使う必要がありますが、簡易的にアクセス制限を施したい場合などは、これらのHTTPによる認証で事足りるでしょう。 そのうち基認証は、簡単なのでよく利用されます。基認証では、ユーザーが入力したパスワードは、BASE64という方法で符号化されてネットワーク上を流れます。このBASE64符号化は、そもそも暗号化のための方法ではなく、符号化のアルゴリズムを知っているものならば、誰でも簡単に解読できてしまうものです。そのため、認証時の通信を傍受されると、パスワードが簡単に取得されてしまい、基的に安全ではありません。 通信経路の秘密性を保つには、SSL(Server Socket L

    Tomcatでダイジェスト認証を使う
  • Tomcatのパスワードをダイジェスト化する

    Tomcatでは、基認証やダイジェスト認証などの認証方法を利用することができます。しかし、パスワードは平文(暗号化されていない普通のテキストファイル)で保存されるため、パスワードが保管されているフォルダへのアクセス権を持つ人に、パスワードを知られてしまう危険性があります。 このようなパスワードの漏えいを防ぐために、ハッシュ関数を用いてパスワードをダイジェスト化して格納しておくという方法があります。ダイジェスト化されたパスワードから元の平文パスワードを復元することは、非常に難しいとされています。従って、万一ダイジェスト化されたパスワードが他人に知られてしまっても、そこから元のパスワードを知られてしまう危険はまずありません。 ユーザー認証の際は、ユーザーが送信した平文パスワードを同じアルゴリズムのハッシュ関数を用いてダイジェスト化し、このダイジェスト化されたパスワード同士を照会することによっ

    Tomcatのパスワードをダイジェスト化する
  • OpenID とは:ITpro

    「OpenID」は,一つのIDでインターネットのさまざまなWebサイトの認証を実現するしくみである。IDにURLを使うのが特徴だ。米国ではすでに,30余りのWebサイトがOpenID認証に対応している。米AOLやWikipediaが対応を表明したほか,マイクロソフトのビル・ゲイツ会長も支持を表明している。国内ではニュース情報共有サイト「Choix」を運営するアセントネットワークスがOpenIDのID発行サービス「Openid.ne.jp」を始めた。 OpenIDの発行/認証サイトは,ユーザー名やメール・アドレスなどの情報を登録することでIDを発行してくれる。IDは,「ユーザー名+発行/認証サイトのドメイン名」という形になる。例えば,Openid.ne.jpに「nnw」というユーザー名で登録すると,「nnw.openid.ne.jp」がIDとして割り当てられる。 OpenIDを使うと,Ope

    OpenID とは:ITpro
  • OpenID認証の仕組み(想像)

    ■ Streamripperその後 先月仕掛けたStreamripperだが、ほったらかしにしておいたらこんなことに: % du -h ~/var/mp3 8.7G /home/sho/var/mp3 % df Filesystem 1K-ブロック 使用 使用可 使用% マウント位置 /dev/hda1 38811816 31140276 7671540 81% / ぎゃ、もう10GB目前じゃん。RadioioJazzは64kbpsなので、128kbps換算にすると17GB相当である。ぜんぶ聴くのに何日かかるやら。つーかディスクの使用量が80%を超えてしまったので、しばらく休もう。 ■ OpenID認証の仕組み(想像) 今日のパワポ仕事に飽きたので、余勢で1枚。 なんとなく盛り上がっていることを察してVidentiry.org上にページを確保したのはいいが、何が面白いのかさっぱりわからない

  • Google Calendar に見る RSS 認証の今後の方向性 : 管理人@Yoski

    先日リリースした toread.cc (あとで読むの英語版) がすごいことになっていて少々バタバタしつつも(「あとで」レポート書きます)、ひとまず落ち着いたエントリを。 さて、各所で話題になっている Google Calendar について。 (レビューは 秋元さんのブログ などで簡潔にまとめられていますので、そちらを参照して頂くとしてここでは割愛します。) さて、私が注目したのは Google Calendar の Atom フィードの配信方法です。 以前から「認証が必要なパーソナルデータをフィードで配信する方法」についてはいろいろな議論がなされていました。 少し前に一番基的で確実といわれていたのが HTTPS + 基認証 を用いる方法で、実際 GMail のフィードではこの方式が用いられています。 ※ GMail Atom フィード: https://gmail.google.co

  • Kazuho@Cybozu Labs: RSS Feed と認証

    « mod_webdev | メイン | フィードビジネス・カンファレンス リンク集 » 2005年12月08日 RSS Feed と認証 日 (12月8日) フィードビジネス・カンファレンス (FBS カンファレンス) で RSS Feed の拡張について話しました(資料は後ほどカンファレンスのページで公開されると思います)。カンファレンスでは Podcasting を始めとするさまざまな RSS の拡張を紹介したのですが、エントリでは、その中で説明した RSS Personalization について書きたいと思います。 I. 背景 RSS は今日、現在ブログやニュースといった、主に公開情報を配信するために使われています。しかし今後は、Eコマースや社内ソフトウェア、SNS といった認証やパーソナライゼーションが必要な分野でも使われていくだろうと考えられます。 現時点でも Basic

  • Authentication/Identity for Mashups: blog.bulknews.net

    Authentication/Identity for Mashups マイミクマップ というアプリケーションがあります。 mixi に登録している自分の友達の出身地あるいは現在地を調べて Google Maps でプロットするという、典型的な Web 2.0 的アプリ。mixi のデータと Google Maps API の remix (Mashup) であり、とってきたデータを視覚的に見せる (Data Visualization) と、Web 2.0 の王道をいっている感じでグッジョブ!といいたいところなのですが、ひとつ決定的に残念なのが、 パスワードやメールアドレスを入力することに不安がある方は、一旦メールアドレス、パスワードを変更してからご利用いただき とあるように mixi のIDとパスワードを渡してログインさせてスクリーンスクレイプしてデータをとってきているところ。これは

  • 2006年は認証APIの年

    Webカレンダーの30Boxesが「出す」と宣言していたAPIの一端を公開した。まだイベントの作成と更新が公開されていないが、それが出れば手元のツールと同期するプログラムとか簡単に書けそうだ。 GoogleAmazon、eBayで始まったWeb APIの大きな流れは、当初の読み取り専用データのWeb公開(Open Data!)を経て、Flickr APIとその仲間たちやAtom PPのような更新できるAPI(をSPIと呼んだこともあったっけ)へと歩を進めつつある。 更新できるAPIで重要なのは、認証機能だ。30Boxesも、カレンダーにデータを追加することを念頭においているわけだから当然だが、最初から認証機能が用意されている。こんなAPI呼び出しでユーザーの承認を受けることができる。Flickrとその仲間たちも同じような仕組みでユーザーがアプリへ承認を与えることができる。Amazon W

  • Kazuho@Cybozu Labs: Web Identity Syndication (WEIS)

    表の各項目について説明します。なお、以下では WEIS の仕様に準じ、リソース (データあるいは機能) を提供するウェブサイトを Provider、それを利用するウェブサイトを Consumer と呼びます。 ・スケーラビリティ Consumer が Provider 毎にサービスをカスタマイズする必要があるかどうか、を示すのがこの項目です。 flickr や 30 boxes の承認 API は自社のアプリケーションに密結合されています。また、無知な Consumer がリソースにアクセスしようとして認証を要求された場合に、どのようにして認証トークンを要求すればよいか、発見 (Discover) する仕組みを持っていません (つまり、認証 API の URL について、 Consumer が事前に知っておく必要がある) 。 したがって、flickr や 30 boxes の API は、