WordPress 기고자는 WP REST API를 위한 경로를 찾습니다.

게시 됨: 2016-02-09
사진 제공: 발레리 폴토락
사진 제공: 발레리 폴토락

주말 동안 Matt Mullenweg와 Ryan McCue가 WordPress 블로그에서 지난주 상태 회의의 진술을 명확히 하기 위해 WP REST API의 방향을 둘러싼 토론이 계속되었습니다. 의견의 차이로 인해 API의 핵심 준비에 대한 목표를 구성하는 요소에 대한 열띤 토론이 벌어지고 있습니다.

"Chicken and Egg"라는 제목의 게시물에서 Mullenweg는 최근 WP REST API 토론에 대해 언급하면서 90년대 중반 힙합 시대의 역사를 다룬 책의 일화를 공유했습니다.

나는 Questlove가 노래에 뭔가 빠져 있다는 것을 깨닫고 대상 청중에게 반향을 일으킬 때까지 부스로 돌아가 계속 작업하는 아이디어를 좋아합니다. 단독으로 존재하지 않는 노래는 앨범의 일부로 번들로 제공될 때 이보다 더 좋을 수 없습니다. (아니면 삼성이 Android에서 가장 인기 있는 앱을 갖게 될 것입니다.) 팬들은 각 트랙의 관리와 품질을 듣고 열렬한 팬이 됩니다.

Mullenweg는 웹용 제품을 구축할 때 고려 사항을 다음과 같이 설명합니다.

우리가 생산하는 모든 것에는 이러한 긴장이 있습니다. 1.0이 가장 외롭고 최소한의 실행 가능한 제품 사이의 경계선은 어디입니까? 아니면 최소한의 사랑스러운 제품에 관한 것입니까? 우리는 에어컨이 없는 자동차를 만들고 있습니까, 아니면 바퀴가 없는 자동차를 만들고 있습니까?

'피벗'은 이제 통과되었지만 배포가 작동하지 않는 제품의 핵심을 해결할 것이라고 가정하는 것은 훨씬 더 나쁩니다.

Mullenweg은 지난주 회의에서 동일한 자동차 비유를 언급했습니다. 비유가 REST API에 어떻게 적용되는지에 대한 자세한 설명을 요청한 댓글에 대해 Mullenweg는 다음과 같이 말했습니다.

일반적으로 좋은 휴리스틱을 사용하려면 에어컨이 있기 전에 수십 년의 자동차, 수백만 대의 차량 및 운전자가 있었습니다. 자동차의 핵심 가치 제안은 운송이며, AC는 당신이 더 편안하게 갈 수 있도록 도와줍니다. AC를 받기 위해 차가 필요하지 않았습니다. 집에 있으면 됩니다. AC는 다른 차보다 한 차를 선택하게 할 수 있지만 차에 AC가 없으면 걷거나 말을 타지 않을 것입니다. 그냥 창문을 내리면 됩니다.

이것은 바퀴를 구성하는 요소가 무엇인지에 대한 질문을 던집니다. 이 토론에 기여한 사람들은 기존 엔드포인트가 코어에 병합될 준비가 되었는지 여부에 대해 의견이 나뉩니다. 많은 사람들이 이미 프로덕션에서 API를 성공적으로 사용하고 있는 WP REST API 팀 구성원은 엔드포인트가 이제 준비되었다고 믿습니다. API의 현재 상태는 WordPress 안팎으로 콘텐츠를 가져오는 기능을 제공하여 많은 사람들이 주요 사용 사례라고 생각하는 다른 플랫폼과 더 쉽게 통신할 수 있도록 합니다.

지난 주 토론에 참여한 Mullenweg와 다른 사람들은 wp-admin에서 사용할 수 있는 모든 것을 지원하는 REST API인 더 완전한 것을 제공하는 데 찬성합니다. 여기에는 WordPress의 많은 사이트 관리 기능이 포함되며 API 여러 릴리스를 핵심 준비 상태에서 멀어지게 합니다.

초기 보고서에 대한 논평에서 Drew Jaynes는 견고한 도약점을 제공하는 중간 지점이라고 믿는 것을 옹호했습니다. 여기에는 병합하기 전에 기존 엔드포인트에서 누락된 부분을 해결하는 것이 포함됩니다(암호로 보호된 게시물, 자동 저장 및 게시물 미리보기, 메타와 같은 항목).

"저와 기고자/커미터 진영의 다른 사람들이 채팅에서 말했듯이 중간 지점이 있을 수 있습니다."라고 그는 말했습니다. 그는 "4개의 핵심 엔드포인트만으로 끝나는지 여부는 약간의 풍미, XML-RPC 패리티 또는 일부 wp-admin 패리티 측정이 있는 4개의 핵심 엔드포인트"라고 말했습니다.

Ryan McCue는 "WordPress REST API를 통한 점진적 개선"이라는 제목의 게시물에서 지금 배포를 추진하고 향후 릴리스에서 더 많은 엔드포인트를 출시할 완전한 반복적 접근 방식을 설명했습니다.

점진적 개선은 몇 가지 관련 문제에 대한 핵심 솔루션입니다. WordPress의 향후 기능 및 버전과의 순방향 호환성, WordPress의 강력한 데이터 유형 처리. 점진적 개선은 REST API 프로젝트의 차단을 해제하고 REST API가 WordPress 관리자의 모든 기능과 동등해질 때까지 기다릴 필요가 없도록 합니다.

McCue의 게시물은 REST API의 기능 감지 기능에 대해 자세히 설명합니다. 이를 통해 개발자는 핵심 지원을 기다리는 동안 기능에 대한 지원을 쉽게 감지하고 앞으로 호환 가능한 방식으로 빌드할 수 있습니다.

유통이 답인가?

지난 주 회의에서 McCue는 기능 플러그인으로 프로젝트 개발을 계속하는 것은 득보다 실이 많을 것이라고 말했습니다. REST API가 wp-admin의 모든 것을 지원하지 않고 출시되도록 허용되지 않으면 팀은 WordPress 코어의 어려운 장애물을 동시에 해결하는 동시에 기능 플러그인으로 계속 반복해야 합니다. 프로젝트에서 파트 타임 미만으로 작업하는 주요 기여자 4명으로 인해 이 요구 사항은 WP REST API를 무기한 중단할 수 있습니다.

McCue는 "우리는 점진적 개선 접근 방식이 API 개발을 지속하기 위한 최선의 접근 방식이라고 믿습니다. "향후 10년 동안 (이전 버전과의 호환성을 깨지 않고) 추가하려는 API라면 점진적 개선은 REST API 프로젝트가 채택해야 하는 패러다임입니다."

워드프레스 역사 전반에 걸쳐 개발에 대한 반복적인 접근을 주도해 온 Mullenweg는 앞으로의 유일한 방법으로 배포에 집착하는 것을 경계합니다.

워드프레스 사용량이 많을수록 발소리가 커집니다. 수백만 개의 사이트에 배포되는 핵심 REST API를 반복하면 기여자가 아직 예측할 수 없는 방식으로 웹에 영향을 줄 수 있습니다. 그들이 말했듯이, 왕관을 쓰는 머리는 무겁습니다. 잔물결은 WordPress 사이트를 넘어 API도 사용하는 외부 플랫폼으로 확장됩니다.

기고자들은 여전히 ​​코어에서 반복적인 개발과 보다 완전한 API를 제공하는 것의 미묘한 차이에 대해 논의하고 있습니다. 한편, 프로젝트를 둘러싼 불확실성과 여전히 플러그인 종속성을 갖고 있다는 사실 때문에 채택이 지연되고 있습니다. WordPress 기고자가 Mullenweg의 권장 사항에 반대하여 끝점을 포함하도록 파고들 것인지 아니면 기존 끝점을 다듬는 데 더 많은 시간을 할애할 것인지는 아직 명확하지 않습니다. WP REST API 팀이 API가 wp-admin 교체를 지원할 수 있는지 확인해야 하는 경우 올해 말이나 그 이후까지는 코어에 상륙하지 않을 수 있습니다.