商社中抜き論に対する反論
転売についての議論のたびに「商社だって中抜きしてるじゃねーか」という意見が出てくるのでここで反論をしておきたい ■「中抜き」ではなく、「売掛金回収リスクを負う」ことに対する対価としてのフィー 増田食品が新しくカップラーメンを開発し、全国のスーパーに販売を行うとする スーパーは現金取引はしてくれないので、掛け(月末締め翌月末現金払い)だったり手形での回収となり、増田食品は売掛金の回収リスクを負うこととなってしまう 増田食品に全国のスーパーの支払能力を調査することは難しい そこで間にはてな商事(商社)に入ってもらうわけである 増田食品は1～2％程度の手数料を払うかわりに、与信管理を全て商社に丸投げすることが出来る 仮に販売先のスーパーが倒産したとしても、増田食品ははてな商事から代金を回収するため影響を受けることがない ■長期プロジェクトの期間中のリスクを引き受けることの対価としてのフィー 国内
POSTリクエストを冪等処理可能にするIdempotency-Keyヘッダの提案仕様 - ASnoKaze blog
はじめに HTTPリクエストには冪等なものと非冪等なものがあります。 仕様上、GETやOPTIONSは冪等であり、同じリクエストであれば何度行っても問題ありません。そのため通信上エラーが起こっても自動的にリトライすることが出来ます。 一方で、POSTリクエストは冪等ではありません。同じリクエストでも複数回行うと、結果が変わってしまいます。投稿や課金APIであれば2重に処理されてしまいます。 POSTリクエスト中にタイムアウトが発生した時に、サーバに処理される前にタイムアウトしたのか、サーバが処理したあとにレスポンスを返そうとしたところでタイムアウトしたのかクライアントは区別できません。そのため、POSTリクエストを一概にリトライすることは出来ません。 そこで、リトライにより複数回同じPOSTリクエストを受け取っても、同じものと識別できるように識別子をHTTPリクエストに付加できるようにする
Web 技術の調査方法 | blog.jxck.io
Intro 「新しい API などを、どうやって調べているのか」「仕様などを調べる際に、どこから手をつければ良いのか」などといった質問をもらうことがある。 確かにどこかに明文化されていると言うよりは、普段からやっていて、ある程度慣れてきているだけなものであり、自分としても明文化していなかったため、これを機に解説してみる。 やり方は一つではない上に日々変わっていくだろうが、頻繁にこの記事を更新するつもりはない。また、筆者は実務で必要になるというよりは、ほとんどを趣味でやっているため、このやり方が合わない場面は多々有るだろう。 スコープとしては、ライブラリ、ツール、フレームワークなどではなく、 Web プラットフォーム関連の標準やブラウザの実装状況などに限定している。 Scope 従来からあり、広く認知された API については、情報も多く調査の敷居はそこまで高くないため、今回は議論が始まって
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
