米Oracleが米Googleの「Android」にJavaの知的所有権を侵害されたと主張している訴訟で、米連邦巡回控訴裁判所は現地時間2014年5月9日、問題とされるJava APIは著作権法による保護の下にあるとの判決を下した。 Oracleは2010年に、AndroidがJava関連特許および著作権を侵害しているとして、Googleをカリフォルニア州北部連邦地方裁判所に提訴した。2012年5月の裁決では、Googleによる特許侵害は認められなかった（関連記事：Javaの知的所有権を巡るOracleの訴訟、陪審はGoogleによる特許侵害を認めず）。またAPIの著作権については、陪審はGoogleによる一部侵害を認めたものの（関連記事：Oracle対Google裁判、陪審がAndroidにおける一部著作権侵害を認める）、裁判所は著作権の対象ではないとの判断を下した。Oracleはこれを
周回遅れ感が半端ないけどバージョニング関連で色々読んで・聞いて思ったことを書く。 APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight Kazuho's Weblog: 拡張可能なWeb APIの設計原則と、バージョン番号を使う理由について Rebuild: 35: You Don't Need API Version 2 (Kenn Ejima) rest - Best practices for API versioning? - Stack Overflow RESTfulなサービスのバージョンングから得られた知見 RESTとバージョニング 基本的にいわゆる狭義のRESTとAPIのバージョニングは何も関係ない。強いて言えば、HATEOASはバージョニングにも使えるよ、というのがREST信者の主張であるものの、それが正しい（というか実用的）かど
APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sightにはブコメしたのですが、Rebuild: 35: You Don't Need API Version 2 (Kenn Ejima)でも本件に言及があったようなので、少し一般論を書いておきたいと思います。 ■Web APIの設計原則について そもそも、良いAPIとはどのような特性をもつものでしょうか？ 一般的に、以下の２点が挙げられると思います。 拡張が容易である 拡張時に後方互換性を破壊しない ウェブの場合は、これに加え、 スケーラブルである HTTPに起因する問題に上手に対処できる ことが求められます。 前２者はウェブに限らない要件です。これを満たす設計手法としては、 リクエストおよびレスポンスのパラメータを拡張可能に 互換性を壊す拡張が必要な場合は、関数名を変える 古い関数は従来と同じ機能を
ちょっと前にTwitterでAPIのバージョニングをどうやるかみたいな話をしていたのですが、そのへんもやもやしているので少し整理しておきたいなと。 APIのURLを/api/v1/*とかってやるの、やめたほうがいいとおもうんだけどなぁ。いざv2を作るとなったときに、大量のコピペが発生して後悔するよ、って伝えたい。— Kenn Ejima (@kenn) February 28, 2014 さて、これについて色々と異論・反論も含めた意見が出たのですが、まずは、大昔にURL方式（＝コントローラ分割）でやってきて後悔したぼくが、（5年ぐらい前から）現在はどうやってAPIのバージョンを管理しているか？について紹介します。 基本原理としては、コピペが多発する根っこで分岐（＝コントローラ分割）じゃなくて、必要最小限のところで限局的に分岐するのがいい、という考え方に基づきます。 一言でいうと、「パラメー
When you’re designing, testing, or releasing a new Web API, you’re building a new system on top of an existing complex and sophisticated system. At a minimum, you’re building upon HTTP, which is built upon TCP/IP, which is built upon a series of tubes. You’re also building upon a web server, an application framework, and maybe an API framework. Most people, myself included, are not aware of all th
<g> <g> <defs> <rect id="SVGID_1_" x="-468" y="-1360" width="1440" height="3027" /> </defs> <clippath id="SVGID_2_"> <use xlink:href="#SVGID_1_" style="overflow:visible;" /> </clippath> </g> </g> <rect x="-468" y="-1360" class="st0" width="1440" height="3027" style="fill:rgb(0,0,0,0);stroke-width:3;stroke:rgb(0,0,0)" /> <path d="M13.4,12l5.8-5.8c0.4-0.4,0.4-1,0-1.4c-0.4-0.4-1-0.4-1.4,0L12,10.6L6.2
At the end of June, I wrote about how we're working to deliver a consistent Twitter experience, and how we would soon introduce stricter guidelines about how the Twitter API is used. I'd like to give you more information about coming changes to the API and the migration plan while offering insights into today's Twitter ecosystem and why we're making these changes. In the coming weeks we will relea
WebDriver W3C Working Draft 05 December 2024 More details about this document This version: https://www.w3.org/TR/2024/WD-webdriver2-20241205/ Latest published version: https://www.w3.org/TR/webdriver2/ Latest editor's draft:https://w3c.github.io/webdriver/ History: https://www.w3.org/standards/history/webdriver2/ Commit history Test suite:https://wpt.live/webdriver/ Implementation report: https:/
Thanks! Please check your inbox to confirm your subscription. If you haven’t previously confirmed a subscription to a Mozilla-related newsletter you may have to do so. Please check your inbox or your spam filter for an email from us. Neel Mehta Great take, Robert. I agree that, for security’s sake, the FileSystem API should not be added – at least right now. There’s always the case of an app sayin
Eyes Above The Waves Robert O'Callahan. Christian. Repatriate Kiwi. Hacker. Archive 2024 October Advanced Debugging Technology In Practice June Waihohonu Hut 2024 So You Want To Build A Browser Engine Real-Time Settlers Of Catan April Auckland Waterfront Half Marathon 2024 Whanganui River Journey 2024 2023 December Rees-Dart Track 2023 Caples/Routeburn Track 2023 Abel Tasman Kayaking November Moun
Hi Chris, Arno and I would like to implement the NFC API as contribution of Deutsche Telekom. Attached you can find a first draft of the API in xpidl format. The API proposal mainly based on phonegap-nfc (https://github.com/chariotsolutions/phonegap-nfc) and Android API (http://developer.android.com/reference/android/nfc/NfcAdapter.html). We also took some other NFC API's (e.g. Qt Mobility 1.2 Con
Ragavan Srinivasan’s post about the forthcoming Mozilla Marketplace for Open Web Apps inspired me to write about Mozilla’s surging Web and Device API standards work. A bit of background. Mozilla has always contributed to web standards, going back to the start of the project. We co-founded the WHAT-WG to kick off HTML5. As readers of this blog know, we are a leader in JS standardization. We have so
米Google、米Microsoft、米Netflixの3社は2月21日（現地時間）、Web標準化団体のWorld Wide Web Consortium（W3C）に対し、暗号化された動画や音楽のHTML5での再生を可能にするためのAPIの標準化を求めるドラフトプロポーザルを行った。 HTML5では、FlashやSilverlightなどのプラグインを使わずに動画や音声を再生できる（Webブラウザによる対応が前提）が、そうしたプラグインと異なり、デジタル著作権管理（DRM）の方法は定められていない。そのため、DRMで保護されたコンテンツを提供するには、Webブラウザや端末別に対応させる必要がある。これは、コンテンツ提供側にとっては大きな負担になっている。 Googleらが提案するシステムでは、APIをWebブラウザに追加することで、HTMLのmediaエレメントに変更を加えることなく、あら
Recently there have been a number of blog posts on optimizations possible via Local StorageAPI. When Microsoft, Google, Amazon and a number of others aggressively adopt a new feature, people notice. The optimization is to use Local Storage to reduce network requests and/or payload size. This should result in a more responsive experience for the user… except when it doesn’t. This strategy can backf
Web ページ内の任意の要素をフルスクリーン表示可能にする Fullscreen API ですが、お勉強ついでに簡単に試してみました。 ちょっと前、先月の話題になってしまうのですが、Web ページ内の任意の要素をフルスクリーン表示可能にする Fullscreen API に関連して、Mozilla が公開している Gecko:FullScreenAPI が更新されて Firefox Nightly で使えるようになったり、W3C からも Fullscreen （Editor's Draft） が公開されたりと色々動きが活発になってきましたので、いい機会ということで、お勉強ついでに簡単に試してみました。 例えば HTML5 で追加された video 要素は、今まで Flash などのアドオンに頼ってきた動画の Web ページへの埋め込み、再生を HTML 側で対応することを可能にしましたが、
Push notifications are a way for websites to send small messages to users when the user is not on the site. iOS and Android devices already support their own push notification services, but we want to make notifications available to the whole web. We’re making prototypes and designing the API right now and want to share our progress. How it works The website gets a URL where it can send notificati
This document provides guidance on designing RESTful APIs. It recommends using nouns instead of verbs, keeping URLs simple with only two endpoints per resource, and following conventions from leading APIs. Complex variations and optional parameters should be "swept behind the '?'." The document emphasizes designing for application developers by making APIs intuitive, consistent and complete while
This document captures common practices in designing APIs that fit well into the Web platform as a whole, using WebIDL [[!WEBIDL]]. As it currently stands, this document is nothing more than a proposal from its editor, with no backing implied or otherwise from any other party. Introduction Over a relatively short period of time the number of different APIs being created for use on the Web has grow
This document discusses device APIs in HTML5 including geolocation, device orientation, and media capture. It notes several working groups at the W3C that are developing device API specifications, including the Geolocation WG, Device APIs WG, and Web Real-Time Communication WG. Key APIs being developed include Geolocation, Media Capture, and a stream API for real-time communication. Links to speci
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
