ポーリングのススメ - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? RPCってあるよね RPCという言葉がある。リモートプロシージャコールの略。平たく言えば、別のマシンの関数を呼び出す。 もっと平たく言えば、別サーバのプログラム呼び出し。 かっこいいのはいっぱいある。 XML-RCP GRPC SOAP そんなところ。特にHTTPを通じて呼び出すには、WebAPIなんて言い方もしている。時間のかかる処理をRPCで呼び出す時にはいろいろ大変。いい案を考えよう。 第一の案：REST-API 一番シンプルな案が、REST-API。一般的な動的なWebスクリプトって、クライアントがブラウザで、サーバのプログラム
gRPCとGraphQL - Qiita
はじめに gRPCとGraphQLをどう使い分けるかがわからず混乱していたので、軽く整理した。 どう違うか GraphQLはAPI用のクエリ言語で必要なデータを指定することで無駄な通信をしないようにすることができる。 一方でgRPCはProtocol bufferを用いてRPC(サーバー上のメソッドをあたかもクライアント側で呼んでいるかのように見せるもの)を実現している。 どちらも、サーバーに対してリクエストを出しレスポンスを受け取るという目的は一緒。 ただ、gRPCはGraphqlのように柔軟なクエリ（関数呼び出し）はない。 サービスという形でRPCの関数を呼び出し結果を得るが、その結果の形は固定。 また、Mediumの記事でも述べられている通り、gRPCは低レベル向き、GraphQLは高レベル向き。 なので、ウェブアプリを作るときには、フロント側がアクセスするAPIはGraphQLで、
トークンを利用した認証・認可 API を実装するとき Authorization: Bearer ヘッダを使っていいのか調べた - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? TL;DR HTTP でトークンを利用した認証・認可をする手法として RFC 6750 がある OAuth に限らず、トークンを利用して認証・認可する機構の一部として Authorization: Bearer ヘッダを使うことができる 使い方について詳しくはこの記事の下のほうに書いた 要求 トークンを利用した認証・認可機構を持つ API を作りたい クライアントがトークンを HTTP リクエストに含めて送信し、サーバはトークンを検証してリソースへのアクセスを許可したい Authorization: Bearer トークン ヘッダでトー
翻訳: WebAPI 設計のベストプラクティス - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? これは Enchant の開発者である Vinay Sahni さんが書いた記事「Best Practices for Designing a Pragmatic RESTful API」1を、ご本人の許可を得て翻訳したものです。 RESTful な WebAPI を設計しようとすると、細かなところで長考したり議論したりすると思います。また、他の API に倣ってやってはみたものの、本当にそれでいいのか、どうしてそうしているのか分からない、何てことも少なくはないと思います。 この記事では、そのようなハマリどころについて Vinay さん
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
