ginpeiのブックマーク / 2016年11月30日

ginpei id:ginpei

2016年11月30日のブックマーク (2件)

Riot はミニマルで Web Components のような UI ライブラリ - Qiita
古典的な構成のサービスを AWS Lambda + S3 で動作するサーバーレスアーキテクチャで再構築し、そのフロントエンドに Riot を採用しました。プロジェクトは WWD JAPAN.com として公開しています。 React や Angular などに代表される JavaScript の UI ライブラリのうち、Riot はミニマルな API と HTML 標準に近い文法を採用しているのが特徴です。 Riot はコンポーネントベースの UI 開発から複雑さを取り除き、楽しさを与えます。 TL;DR Riot はこれまでの UI ライブラリと比べて以下の点で異なります。必要最小限の API 少ないボイラープレート Web Components ( HTML Template ) に似た文法 React のコードと比較してみます。 ToDo アプリケーションを React で書くと
ginpei 2016/11/30
Riot.jsの紹介。『不要な複雑さにまみれた現在の潮流に「反旗」を翻すプロジェクト』。カスタムタグで構築。HTML部と処理部がひとまとめになるので理解しやすい。Web Componentsに近い。

javascript

library

riotjs
リンク
RESTful API設計におけるHTTPステータスコードの指針 - Qiita
RESTful APIを設計した際のステータスコードの指針です。メソッド別 GET 成功した場合 200 OK：最も一般的 304 Not Modified：条件付きGETでキャッシュを使わせたい場合 POST 成功した場合 201 Created 作成したリソースのURIを示すLocationヘッダを付けておく議論 200 OKだとまずいのか？ 200 OKを応答する実装も多くあり、まずいというわけでもない 200 OKはPOST結果がキャッシュ可能、201 CreatedはPOST結果がキャッシュ不可能として分けてもいいが、そこまでする必要があるか？（POSTのキャッシュは一般的ではない） 204 No Contentだとまずいのか？クライアントがPOST結果を事前に全て知っているわけではないのでNo Contentは不親切では？失敗した場合 409 Conflict：作成しよ
ginpei 2016/11/30
メソッドと処理結果によって応答ステータスコードを決める。「議論」も載ってるの嬉しい。

web

network

api

dev

design
リンク
- 2016年12月5日
- 2016年11月30日
- 2016年11月29日