フロントエンド開発者は、バックエンド開発者のためにJSON形式を指定する必要がありますか？
私はプロジェクトのフロントエンドの役割を担っています。私のバックエンドチームメイトに、PHPがJavaScriptに返すJSONの正確な形式を指定する必要がありますか？
たとえば、ここで説明するような形式を使用するように伝えます。
または、自分の役割をできるだけ無菌状態に保ち、バックエンドインターフェイスから必要な入力と出力を簡単に説明する必要がありますか？ （もちろん、これが発生すると、異なるデータ構造形式を処理することが私の側でより困難になる可能性があります）
これは、さまざまな形式の要件と長所と短所について話し合う、一緒に行うべき会話です。
どちらか一方が何が起こるかを指示している場合、あなたは悪いソフトウェアと不幸なチームになってしまうでしょう。
あなたは最も明確にJSONのフォーマットと構造がどのように見えるべきかに貢献するべきです。 APIのコンシューマーであるフロントエンドエンジニアが、データ構造がどうあるべきかを知っているエンジニアであることがよくあります。
あなたは、データを使用し、フォーマットし、ループして、それで作業することになります。あなたはそれをどのように届けたいかについて意見を持つべきです。
ミドルウェア開発の素晴らしい世界へようこそ。プロトコルを開発することは大変な労力と議論になる可能性があり、誰も結果を見ることはできません。
あなたが小さなチームにいるなら、独裁者を避けてください：プロトコルを打ち出すために誰とでも迅速なミーティングをしてください。
中規模のチームは、プロトコルを実行する代表者を必要とする場合があります。
大規模なチームや複雑な組織を持つチームには、プロトコルを制御するためのミドルウェア担当者が必要です。
すべてのケースでドキュメントです！前提条件とは何ですか、事後条件とは何ですか、必須フィールドは何ですか、オプションフィールドは何ですか、副作用は何ですか、どのエラーが返されますか？Keepドキュメントが生きている新しい条件、エラーの種類、または副作用が見つかった場合、それらはドキュメントに追加されます。
また、ドキュメントへの準拠を保証するために、クライアント側とサーバー側の両方の単体テストとシステムテストをお勧めします。
大変な作業のように思えるかもしれませんが、ここでの小さなミスは非常に費用と時間がかかります。
私はなぜそうしないのですか？私たちがプロジェクトについて話しているとき、私たちはプロジェクトに取り組んでいるチームについても話します。使用される機能と構造についての意見を聞くことが期待され、歓迎されるべきです。開発者として、私は個人的にチームメイトの貢献を信じ、評価しています。
「速く行きたいなら一人で行きたい。遠くに行きたいなら一緒に行きなさい」ということわざがあります。