프론트 엔드 개발자가 백엔드 개발자를 위해 JSON 형식을 지정해야합니까?


17

프로젝트에서 프런트 엔드 역할을 수행하고 있습니다. 백엔드 팀원에게 PHP가 JavaScript로 반환하는 정확한 JSON 형식을 지정해야합니까?

예를 들어, 여기에 설명 된 것과 유사한 형식을 사용해야한다고 말해야합니다.

프론트 엔드 소비를 위해 JSON을 구성하는 올바른 방법

아니면 가능한 한 멸균 상태를 유지하고 백엔드 인터페이스에서 필요한 입력 및 출력을 간단히 설명해야합니까? (물론 이런 일이 발생하면 다른 데이터 구조 형식을 처리하기가 더 어려울 수 있습니다)


10
나는 그들이 일반적인 의견을 바탕으로 첫 번째 제안을하는 것이 합리적이라는 것을 알 수있었습니다. 그러나 이것이 첫 번째 제안에서 대화가 중단되는 것은 아닙니다.
Doug T.

말이 되네요!
LazerSharks

4
누군가 JSON에 포함 된 정확한 데이터 형식을 지정해야합니다. 당신도 될 수 있습니다. 실제로, 스펙 작성 경험이 가장 많은 사람이어야합니다.
gnasher729

2
@ gnasher729 : 또는 형식이 너무 단순하여 두 당사자 모두 지정해야 할 자격이 있다고 확신하는 경우 누가 지정 해야하는지 알아야하는 첫 번째 코드를 작성합니다. 이것은 또한 종종 가진 사람 사용하는 것이 좋습니다, 자신의 테스트를 시작하는 가장 빠른 누구든지에 대한 보상 ;-) 일반적으로 한 사람이 항상 대부분의 경험이있는 사람 안 할 말 수를 고려 될 수 이상을 작업에 충분한 사람을 경험하지만 그것은 사람 개발의 문제입니다.
Steve Jessop

답변:


42

이것은 서로 다른 형식의 요구 사항과 장단점을 논의하면서 함께해야 할 대화입니다.

한쪽 또는 다른 쪽이 무슨 일이 일어나고 있는지 지시하면 나쁜 소프트웨어와 불행한 팀으로 끝날 것입니다.


1
말이 되네요! 개발 세계에서 실제로 / 보통 발생하는 일이 궁금합니다.
LazerSharks

5
권리. 당신은 그것에 협력합니다. 약간 복잡한 것이면 이상적으로는 개발이 더 쉽고 빠르도록 양쪽 끝에서 라이브러리가 지원하는 공통 형식을 찾는 것이 이상적입니다.
AE

9

JSON의 형식과 구조가 어떻게 보이는지에 가장 명확하게 기여해야합니다. 저는 API 소비자 인 프론트 엔드 엔지니어가 데이터 구조를 어떻게 이해해야하는지 자주 알고 있습니다.

데이터를 사용하고, 형식을 지정하고, 반복하여 작업하는 사람입니다. 전달 방법에 대한 의견이 있어야합니다.


3

멋진 미들웨어 개발 세계에 오신 것을 환영합니다. 프로토콜을 개발하는 것은 많은 노력과 토론 일 수 있으며, 아무도 결과를 보지 않아야합니다.

소규모 팀에 속해 있다면 독재자를 피하십시오. 모든 사람과 프로토콜을 망치기 위해 빠른 만남을 갖습니다.

중간 규모의 팀은 프로토콜을 해결하는 담당자를 원할 수 있습니다.

복잡한 조직의 대규모 팀 및 / 또는 팀에는 프로토콜을 제어 할 수있는 전용 미들웨어 담당자가 있어야합니다.

모든 경우에 문서화하십시오! 전제 조건, 사후 조건, 필수 필드, 선택적 필드, 부작용, 반환되는 오류 등… 새로운 조건, 오류 유형 또는 부작용이 발견 될 때 문서를 계속 유지 문서에 추가됩니다.

또한 문서와의 적합성을 보장하기 위해 클라이언트 및 서버 단위 테스트 및 시스템 테스트를 모두 권장합니다.

많은 작업처럼 보일 수 있지만 여기에서 사소한 실수는 매우 비싸고 시간이 많이 걸릴 수 있습니다.


아, 전 세계 가이 측면에 전념한다는 것을 알게되어 기쁩니다. 나는 고무가 프런트 엔드와 백 엔드 사이의 구분 측면에서 실제로 도로를 만나는 것처럼 보인다고 생각했다.
LazerSharks

1

난 그냥 왜 안 물어? 우리가 프로젝트에 대해 이야기 할 때 우리는 또한 작업하는 팀에 대해 이야기하며 사용 된 기능과 구조에 대한 의견을 듣는 것이 좋습니다. 개발자로서 저는 팀원의 기여를 개인적으로 믿고 소중하게 생각합니다.

당신은 "빨리 가고 싶다면 혼자 가고 싶다. 멀리 가고 싶다면"라는 말이 있다는 것을 알고있다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.