認証を含む API 開発で検討すべきこと - ボクココ
ども、@kimihomです。 API に関する基礎的な話で、なぜ API が重要なのか、APIの実装で注意する点について記述した。 今回はAPI開発において最も頭を悩ます、認証の問題について考えてみたい。 API における認証 よくあるログインが必要なページを考えてみていただきたい。 通常のWebアプリケーションであれば、Cookieという仕組みを使って毎回Webサーバーにアクセスするときにsession idというものを送信し、それとユーザー情報を紐付けたデータを取ってくることで、どんなユーザーからリクエストが来たのかをWebアプリケーション側で判断することができる。これにより、私たちはいつも閲覧しているWebアプリケーションが自分専用の画面として見れるようになっている。 これがAPIになると話は違ってくる。Cookieという仕組みが使えないのである。ということで、なんとかしてAPIにア
シングルページアプリケーションである必要性を考えよう - ボクココ
ども、@kimihom です。 2019年、皆さんはどんな技術を習得したいと考えているだろうか。その中の候補の一つとして、おそらく「シングルページアプリケーション(以降SPA) を流行りの JavaScript フレームワークで作れるようになる」という目標を掲げている方も少なくないだろう。 私自身 SPA でサービスを作った経験を踏まえて、その価値に関して改めて考え直してみて欲しいと思いこのエントリーを記す。 ユーザーは SPA 自体を求めていない 技術トレンドに流されまくるエンジニアが後を絶たない。 SPA が流行ってるからうちもチャレンジしてみよう あの有名企業が Go を採用したからうちも Go 使ってみよう REST の時代は終わりらしいからうちも考え直そう これらに関して考えるべきことは、「その技術を採用した企業と、あなたの置かれた状況は一致しているのか?」という点だ。実際は全く
なんだかんだで SPA から jQuery に戻った話 - ボクココ
最近は SPA とか React といった話題が尽きないが、自分は結局 フロントエンド JavaScript は jQuery が最もいいと感じている。それはそれら SPA の JavaScript をいじった経験を踏まえての感想。 理由としては、「 やりたいことができにくい 」これに尽きる。 最新を追うということ 自分が最初にSPAを触ったのは AngularJS だった。なるほど、この ng-repeat や $route, $scope などを使えば、今までサーバサイドでやってたようなレンダリングが表側で制御できるようになる！と感動したものだった。この気持ち良さはきっとサーバーサイドでごにょごにょやっていた経験のある人ならなおさら感動するものだ。 さて、じゃあといって「次作るのは SPA のサービスにしよう！」と意気込んで初めて見たとする。それで作っただけで話題になるし、エンジニアと
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
