[過去ﾛｸﾞ] スレ立てるまでもない質問はここで 161匹目 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
104: 2022/09/16(金)13:06 ID:pgB81iJy(2/2) AAS
>>103
これは、FileSystemDirectoryHandle の polyfill(ponyfill)。
場所は：外部ﾘﾝｸ:github.com
105(2): 2022/09/16(金)18:24 ID:cJN3hfhk(1) AAS
web apiを作っていて、どのステータスコードを返せばいいのかで悩んでいます。
400番台と500番台の使い分けを、皆さんどのようにしていますでしょうか？
例えば、ユーザー情報を更新するAPIで
指定したユーザーIDの情報がDBに無い時、もしくは2件以上ある時、その他の論理状態がおかしい時。です。
以下のように400番台の理屈も、500番台の理屈も思いつくので、どちらが正しいかで悩んでいます。
ユーザー情報がない時に限れば404かなという気もしますが、その他の論理異常の時と同じにしたいという思いがあります。
サーバーからすれば「そのリクエストしたIDがおかしいんだからアプリが悪い。同じリクエスト投げても状況は変わらない」と言いたいのですが
この場合はクライアントサイドが原因なので400で良い気もする。
DBの状態が原因なんだから500エラーなのかなという気もするのですが、そうなると究極的には全部のエラーが500番台のエラーになる気もする。
そもそもDBに対象のユーザーIDが無い(複数ある、論理異常)時は明らかにバグだ。バグ前提で考えるのは良くない。
とすると、おかしいのはリクエスト。だから400番台。
と、自分の中でどっちが正しいのか悩んでいる状態です。
106(1): 2022/09/16(金)19:17 ID:6w/ivPAn(1) AAS
>>105
素人だけどCGIとかの実行エラーなんだからそういうのは全部500番代だと思ってた
ファイルがないとかアク禁とかデーモン側のみでスクリプト抜きの話は400番代で
107(1): 2022/09/16(金)19:37 ID:oAyMZKxN(1/2) AAS
400番台: クライアントに原因のあるエラー (送ったデータに不備ありなど)
500番台: サーバーに原因のあるエラー (データ仕様は正しいがサーバ側の処理が失敗したなど)
不正IDを送られた時に存在しないという結果を返すのはサーバー側から見たらそれが正しい動作なんだから送信側のエラー
108: 2022/09/16(金)19:42 ID:oAyMZKxN(2/2) AAS
てか500て実行時エラーとかDBが落ちてるとか要求の受付時間外とかそういうのじゃない
109: 2022/09/16(金)21:34 ID:Pdv1nxJ2(1) AAS
基本は>>107の書いてるようにクライアントとサーバーのどちらに原因があるか
指定したユーザーIDがDBにないのは400番台
指定したユーザーIDがDBに2件以上あるのがDB不整合の状態なら500番台
原因も対処方法が違うのに同じにしたいというのが間違い
110: 2022/09/16(金)23:14 ID:R7zfJ/61(1) AAS
そもそもバリデーションエラーやら処理している段階でエラーみたいな内部的なものは
成功時は例えばstatus: 0とか返して正常終了を示す
失敗時はstatus: 1とか内部で設定したエラーコードを返すのが一般的では？
HTTPのエラーコードはwebサーバーなどの都合で発生したエラー用だと思うが
111: 2022/09/16(金)23:28 ID:2cEUPRtN(1) AAS
APIが0を返したら正常終了とか古き良き香りになりにけり
RESTful APIならある程度はスタンダードに沿いつつ
ユーザーの責務が何で自分の責務が何かは仕事では必ず決めないといけないんだからそのノリで個々に線引きしていけばいい
112(1): 105 2022/09/17(土)14:24 ID:iAB+KSrH(1) AAS
>>106-
ありがとうございます。
DBにレコードが2件というのは例として不適切でしたが、
とりあえず400を積極的に使う事にします。
113: 2022/09/17(土)14:51 ID:EEEbWrXO(1) AAS
> とりあえず400を積極的に使う事にします。
ダミだこりゃ
114: 2022/09/17(土)15:37 ID:slnpqWSw(1) AAS
>>112
指定したユーザーIDの情報がDBにないという例のほうが論理異常の例として不適切なんだが
115(1): 2022/09/18(日)01:28 ID:X0tGJ0Vt(1) AAS
>>103
その[kAdapter]は単なるクラスフィールド宣言
this[kAdapter]はそのフィールドへのアクセス
this.hogeがthis["hoge"]と同じことを思い出そう
そして今回はそのkAdapterをシンボルで与えているだけ
const kAdapter = Symbol('adapter')
116(1): 2022/09/18(日)19:43 ID:fB0C0iJE(1) AAS
>>115
有難き幸せ。
constructor (adapter) {
super(adapter)
this.adapter = adapter;
}
と書くのとの違いは？
117(1): 2022/09/18(日)22:12 ID:VjUDO6tf(1) AAS
モバイルアプリで使うようなウェブサイトから画像持ってくるようなやつってURLとかのほうが表示速いのかね？
完全に趣味だけどウマ娘HPのHTMLに記されたsrcの文字を指定するだけですぐ反映されるんかな？
118(2): 2022/09/19(月)08:55 ID:E2P5O1UU(1) AAS
>>116
違う
this["adapter"] ←これがthis.adapterと同じ
this[adapter] ←今回はこの形
ここで変数adapterが"adapter"なら同じだが
今回は変数adapterがSymbol("adapter")
つまり両者は異なる
>>117
CDNキャッシュの恩恵に預かれるから独自プロトコルで持ってくるとの比較ならば速くなりうる
119: 2022/09/19(月)10:00 ID:Guc0YHbo(1) AAS
>>118
なるほどサンクス
120: 2022/09/19(月)10:19 ID:pZPXfhQS(1) AAS
画像が通信経路で勝手に再圧縮されてハッシュが一致しないエラーなんてのがあったな
121(1): 2022/09/19(月)10:48 ID:9VJdPhWh(1/2) AAS
プロパティにSymbolを使っている理由はプライベートっぽく保護したいからじゃないかな
this.adapterだと外部から自由に読み書きできるけどthis[adapter]だとadapterの値にアクセスできない限り読み書きの手段がかなり限定される
122: 2022/09/19(月)12:02 ID:knJx8Iiy(1/3) AAS
>>118
(あなたがadapter変数としているものは、今回の例では、kAdapter変数ということを
前提として)
kAdapter が変化するならわかるが、今回は
const kAdapter = Symbol('adapter')
と絶対に変化しない定数のようになっているので、結局、何がやりたいのだろうか？
俺はそもそも、Symbol オブジェクト(?)の役割が分かって無い。
123: 2022/09/19(月)12:04 ID:knJx8Iiy(2/3) AAS
>>121
なるほど。
でも、そういうためだけの目的？？
124(1): 2022/09/19(月)12:25 ID:9VJdPhWh(2/2) AAS
Symbolはユニークなオブジェクトを作る
Symbol('adapter') != Symbol('adapter')
コンストラクタに渡す文字列はただの説明文
125: 2022/09/19(月)12:30 ID:oXPlRBsf(1) AAS
Symbolの説明はとほほが分かりやすかった
外部ﾘﾝｸ[htm]:www.tohoho-web.com
126: 2022/09/19(月)13:30 ID:knJx8Iiy(3/3) AAS
>>124
そもそも new Symbol("xxx") でなくて Symbol("xxx") と書く理由も
俺は分かってない。
127: 2022/09/19(月)13:34 ID:/08McGz8(1) AAS
new なしでクラスのインスタンス作れるというと Kotlin のようだな。
128(1): 2022/09/19(月)22:29 ID:s9D2fBDK(1/2) AAS
new の有無が話題になるのは、JavaScript かな？
例えば、Number のnew の有無
Number() コンストラクターは、 Number オブジェクトを生成します。
new Number(value)
他の型の値は、Number() 関数を用いて数値に変換することができます。
Number('123') // 数値 123 を返す
つまり、newでインスタンスを作る。
new無しは変換関数
129(1): 128 2022/09/19(月)22:36 ID:s9D2fBDK(2/2) AAS
>>128
みたいな、ちょっとした書き方の違いで、様々な機能を実現しているから、JavaScript は難しい。
他にも、==, === の違いとか、一々調べないといけないから、時間の無駄
だから、Ruby の方が圧倒的に分かりやすくて、バグらない。
短時間で済む
130(2): 2022/09/19(月)22:56 ID:3GNptN3X(1) AAS
>>129
ただ、Rubyは
・ちゃんとしたローカル変数が作れない。
・ブロックが中括弧ではなく end などで終わったりして面倒。
if 文の書き方が C言語と異なる。一方、JSは同じ。
・ブロックの書き方に統一感が無い。
・複数行コメントが簡単には書けない。
・Cの構造体の様なものが書きにくい。JSだと書ける。
JSはやりたい事が大体出来るようになっている。
ただし、Promiseなどがメンドクサイ。
131(1): 2022/09/20(火)00:19 ID:u2od2H+V(1) AAS
>>130
>・ちゃんとしたローカル変数が作れない。
ちゃんとしたローカル変数って何？
132(1): 2022/09/20(火)13:00 ID:A6jC1TrN(1) AAS
>>131
ブロックの中でのみ有効で、ブロックが終わると、外からは参照できない
変数の事。
133(1): 2022/09/20(火)13:50 ID:Vc6tzv7n(1) AAS
>>132
それRubyは作れるでしょ
他の言語か何かと勘違いしてない？
上下前次1-新書関写板覧索設栞歴
あと 869 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.170s