WebVR API - Web API | MDN
非推奨: この機能は非推奨になりました。まだ対応しているブラウザーがあるかもしれませんが、すでに関連するウェブ標準から削除されているか、削除の手続き中であるか、互換性のためだけに残されている可能性があります。使用を避け、できれば既存のコードは更新してください。このページの下部にある互換性一覧表を見て判断してください。この機能は突然動作しなくなる可能性があることに注意してください。 非標準: この機能は標準ではなく、標準化の予定もありません。公開されているウェブサイトには使用しないでください。ユーザーによっては使用できないことがあります。実装ごとに大きな差があることもあり、将来は振る舞いが変わるかもしれません。 WebVR は、バーチャルリアリティデバイス — 例えば Oculus Rift のようなヘッドマウントディスプレイ — をウェブアプリへ公開し、ヘッドマウントディスプレイの位置や動
RESTのベストプラクティス | POSTD
現在ではREST APIはとても一般的な話題です。ほとんどすべてのWebアプリケーションの一部分となっています。シンプルで一貫性があり実際的なインターフェースは必須です。これは皆さんのAPIを他の人が使うことをとても容易にします。皆さんにとってはRESTの実践が日常的に感じられるかもしれませんが、RESTをあまり尊重しない人々もよく見かけます。これがRESTについて投稿するきっかけでした。 この記事にはRESTfulなAPIを設計する時に考慮すべきベストプラクティスがあります。 注意 : ここでのベストプラクティスは、私が過去の経験に基づいて良いと考える事例です。もし違う考えをお持ちであれば、お気軽にメールをくだされば意見交換できると思います。 APIのバージョンを示す APIのバージョンは必須であるべきです。これがあると時間が経ってAPIが変わっても影響を受けません。その方法の1つはUR
WebAPIを勢いで作って失敗した小話と解決のポイント - アニメイトラボ開発者ブログ
この記事はanimateLAB Advent Calendar2015 7日目の記事です。 はじめまして。アニメイトラボに11月からWeb/アプリエンジニアとしてジョインしましたかんがー（@KangalMi）と申します。 新卒で入社した会社から非公開なWebAPIとiOS/Androidアプリの開発を行ってきました。 現在はアニマートのWeb側をメインに担当をしています。 今回は、僕がWebAPIを開発・運用する中で失敗したことをお伝えします。 エラーコードの上手な表現方法 自分が開発したものではエラーの表現を下のような形で常に返却していました。 "meta": { "status": 500, "message": "ユーザーの作成に失敗しました。" } 上記はmeta以下にエラー関連の情報をエンベロープで包み、statusはHTTPステータスコードに準拠したコードを、messageには
Web APIにはJSONベースのフォーマットを使おう - Qiita
{ "response": { "id": 3342124, "message": "Hi!", "user": { "id": 3456, "name": "Taro Yamada", "image_url": "/images/taro.png" } } } など、どの構造がいいでしょうか？ もっと違う構造も考えられます。 JSONはシンプルですが、構造に制約がなさすぎます。適切な設計を行うには適切な制約が必要です。 そこで、plain JSONに少し制約を加えたJSONベースのフォーマットを使うことをおすすめします。 もしあなたが、JSONレスポンスをどのようなフォーマットにするかをチームで議論したことがあるなら、JSON APIは『自転車置き場の議論』に対抗する武器となる。 共有された規約に従うことで、生産性が向上し、汎用的なツールを利用でき、アプリケーションという重要なものに集中
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
