REST API 목적?


17

우선, 나는 이것이 현재 시점의 플러그인이라는 것을 이해하지만 어쨌든 WordPress의 거의 부분입니다. 그래서 이것이 주제가 아닌 주제로 표시되지 않기를 바랍니다.

나는 그들의 공식적인 문서, 많은 다른 기사를 보았고 튜토리얼 비디오를 보았지만 여전히 몇 가지 요점을 얻지 못했습니다. 이것은 확실히 WordPress의 미래입니다. 모바일 앱 개발 및 데이터 사이의 데이터 사용 / 공유에 매우 편리합니다. 다른 사이트이지만 내 사이트에만 적용되는 것은 무엇입니까?


이걸 고려하세요:

현재 댓글 작업 중입니다. 사용자가 주석 섹션으로 스크롤 할 때만 주석 섹션을로드하고 싶습니다 (-200px 오프셋으로 지연되지 않음) .

  • 사용자가 해당 지점으로 스크롤 할 때 Ajax 호출을 트리거하려고합니다.
  • 아약스 호출처럼, 그것으로 어떤 데이터를 전송 post_id
  • WP_Comment_Query()서버에서 실행
  • JSON주석 관계, 이름, 컨텐츠 으로 고객 에게 데이터를 다시 보냅니다.
  • 를 사용하여 자바 스크립트 document.createElement(), innerHTML 생성 및 출력 댓글

자 .. 왜 REST API를 대신 사용합니까? 저의 용도는 무엇입니까? 미래에 대비해?

여전히 JavaScript를 사용하여 얻은 모든 데이터를 출력 해야합니다. REST API를 사용해야하는 이유 또는 무엇에 대한 좋은 기사를 찾지 못했습니다 (사이트와 모바일 앱 개발 간의 데이터 전송 제외) ..


위에서 설명한 방식에 따라 REST API를 사용하면 체계 적이고 통합 된 방식 의 이점을 얻을 수 있습니다. 컨텐츠 콜렉터 (주석 쿼리) 또는 응답 형식 (json)을 처리 할 필요가 없습니다. 캐싱과 관련하여 일부 개선 사항이있을 수도 있습니다. 내가 일반적으로 볼 수있는 단점은 템플릿 화가 브라우저로 완전히 이동하여 내 백엔드 개발자의 의견으로는 성능 문제가 발생한다는 것입니다.
David

JSON 데이터를 클라이언트로 다시 보내려면 어떻게 계획하십니까? 서버 측 코드를 어떻게 구축하고 있습니까?
czerspalace


@David 기본적으로 REST API는 모든 쿼리 자체를 수행하며 쿼리 문자열을 매개 변수로 공급해야합니까? templating .. 다행스럽게도 하드웨어는 매년 더 강력 해집니다. 불행히도 그 문제에 관여하기를 거부하는 사람들이 항상있을 것입니다 (오래된 IE 사용자, Im보고 있습니다) .
N00b

@czerspalace 1. WP_Comment_Query() 2. 각각 while루프 3 의 매개 변수 배열로 주석 배열을 구성 합니다. json_encode() 4. echo 인코딩 된 데이터 백. 이 모든 기능 wp_ajax및 / 또는 wp_ajax_nopriv기능.
N00b

답변:


8

현재 상태에서는 유능한 개발자에게 실질적인 이점이없는 잘못 설계된 기능입니다.

이 답변이 작성된 시점의 기본 아이디어는 WordPress 핵심 기능을 JSON REST API로 노출하는 것입니다. 이를 통해 UI에서 WordPress "비즈니스"논리를 분리 할 수 ​​있으며, 워드 프레스에서 정보를 관리하고 추출하기 위해 다른 전체 또는 부분 UI를 작성할 수 있습니다. 이것은 그 자체로 혁명이 아니라 진화입니다. XML-RPC API를 대체하여 제출 API를 위해 HTTP 기반을 간소화합니다.

다른 진화 과정과 마찬가지로, 각 단계마다 자신에게 물어볼 수 있습니다. 이전 상태에서 어떤 이점이 있습니까? 아마도 그 대답은 "별로 많지 않지만"단계가 큰 차이로 누적되기를 바랍니다.

그렇다면 왜이 대답의 부정적인 서문입니까? 소프트웨어 개발자로서의 경험은 구체적인 유스 케이스를 사용하지 않고 실제로 유용한 일반 API를 설계하는 것은 거의 불가능하다는 것입니다. 구체적인 사용 사례는 자동화 된 워드 프레스 관리를 위해 XML-RPC API를 대체 할 수 있지만, 프런트 엔드와 관련된 모든 사이트는 사이트마다 고유해야하며 클라이언트에서 서버로 전송 된 모든 요청에 ​​대해 막대한 성능 저하가 있으므로 사용자가 만족할 수있는 방식으로 원하는 결과를 얻기 위해 다른 API를 함께 사용합니다. 즉, 사소한 사용이 아닌 프런트 엔드의 경우 AJAX 경로와 REST-API 경로를 사용하는 경우 개발 노력에 차이가 거의 없습니다.


고마워요. 상황이 더 나빠질뿐입니다! 어떤 길을 가야할지 진심으로 생각할 수 없습니다. 내가 아는 것은 앞으로 모바일 앱을 만들어야한다는 것입니다. 귀하의 조언은 현재 상태의 REST API가 쓰레기라는 것입니다 .
N00b

아니요, 단지 실제 이점을 보여주지 않는다는 것입니다. 사용 여부에 관해서는, 항상 그렇듯이 더 잘 알고있는 도구를 사용해야합니다. 특히 나머지 API는 여전히 베타 버전이라는 점을 고려해야합니다. 필자는 이미 핵심 인 api 부분에 라우트를 등록하는 것이 좋습니다. 필요한 경우 캐시 할 수있는 URL을 제공하므로 ajax 엔드 포인트로 할 수없는 것입니다.
Mark Kaplun

3

두 가지 중요한 장점은 다음과 같습니다.

  1. 관리자 인터페이스없이 모든 관리 작업을 수행 할 수 있습니다.
  2. 모든 데이터를 표시하고 프런트 엔드 (및 PHP 작성)를 완전히 제거 할 수 있습니다.

구체적으로 예를 들어

3, 4 단계를 REST API로 바꾸고 1, 2, 5 단계를 Backbone.js로 바꿉니다. 붐, 다이내믹 웹 애플리케이션. 또는 파이썬으로 사이트에 필요한 복잡한 라우팅을 수행하는 것이 더 편할 수도 있습니다.


온라인 사용자 모두가 동적 웹 응용 프로그램에서 의미는 매우 주관적이다 (그리고 그들이 그것을 정확히 말하지 않는 이유의) 나는 그것이 비교되는 것을 100 %의 노하우를 것을 의미 하지 동적 웹 사이트 .. 당신의 버전은 무엇입니까? 이것은 REST API를 사용할지 여부를 알아야하는 것과 같습니다.
N00b

2
응용 프로그램은 다른 정적 블로그 페이지로 연결되는 정적 블로그 페이지를 렌더링하는 것 이상의 의미를 지니고 있으며보다 "앱 같은"경험을 제공합니다. 백본 사이트 의 예제로 스크롤 하십시오.
Milo

3

글쎄, 실제로 몇 가지.

  1. 전체 페이지로드의 모든 계산을 요구하지 않고 필요에 따라 특정 기능을 실행할 수 있습니다. 따라서 API 엔드 포인트를 호출하고 페이지의 데이터를 업데이트하여 페이지를 새로 고치지 않고도 오버 헤드가 상당히 적은 메모를 정기적으로 업데이트 할 수 있습니다. 이 개념은 결국 "클라이언트"사이트를 빠르게 한 번로드하는 SPA (단일 페이지 응용 프로그램)로 추정되며 매번 페이지 HTML을 다시 가져올 필요없이 모든 페이지 "변경"을 에뮬레이션합니다. 이것은 Angular, Ember 및 React와 같은 프레임 워크의 출현으로 이미 매우 유명합니다. 사이트는 최종 사용자 (렌더링주기, 비 비즈니스 로직)에 대한 계산 능력을 오프로드하고 서버에 대한 전체 호출 수를 크게 줄이며 필요한 데이터 만 가져옵니다.

  2. 비즈니스 로직과 렌더러를 분리합니다. 예, 다른 PHP 사이트에서 API를 사용하여 결과를 뱉어 내거나 언급 한대로 Javascript로 처리 할 수 ​​있지만 네이티브 모바일 응용 프로그램, 데스크톱 응용 프로그램 등을 사용하여 사용할 수도 있습니다. 하나는 모두 동일한 API와 통신하며, 동일한 비즈니스 로직을 지속적으로 수행하여 API를 사용하는 다양한 클라이언트에서 일관성과 안정성을 만듭니다.

API는 로직과 디스플레이의 문제를 분리하기 때문에 좋습니다.


첫 번째 요점에 대해. 정기적 인 업데이트가 주기적으로 업데이트되고 동적으로 업데이트되는 일반 JavaScript 아약스보다 나은 이유는 무엇입니까?
N00b

2
"일반적인"아약스 호출은 단지 API를 호출하는 것입니다! 실제로 차이는 없습니다. REST API의 목표는 핵심 Wordpress 기능에 이러한 API를 제공하는 것입니다. 이렇게하면 AJAX, 기본 앱, 데스크톱 앱 등을 사용하여 더 많은 작업을 수행 할 수 있습니다. "REST"부분은 API를 쉽게 개발하고 개발할 수 있도록 API를 구성하는 방법을 정의하는 규칙 / 표준 시스템 일뿐입니다. 유지하십시오.
콜트 맥코맥

2

WordPress REST API는 새로운 인기입니다. 단일 페이지 js 구동 응용 프로그램과 WordPresses를 사용하면 응용 프로그램 플랫폼이되고 싶어합니다. 계획은 XML-RPC를 REST API로 대체하는 것입니다 (보안상의 이유로 좋은 것입니다).

https://make.wordpress.org/core/2015/09/21/wp-rest-api-merge-proposal/

  • 뉴욕 타임즈에 새로운 사이트가 구축 된 것 같습니다 .
  • 그것은 (같은 액세스 WP 콘텐츠에 대한 모바일 애플리케이션 및 기타 외부 서비스를 할 수 있습니다 WP-CLI )
  • 개발자가 일주일 동안 가장 많이 사용하는 JSON 소비 프레임 워크로 단일 페이지 앱 프런트 엔드를 구축하고 손끝에서 멋진 상호 작용을 모두 할 수 있습니다.
  • 이를 통해 위에서 언급 한 바와 같이 우려를 분리하고 백엔드 팀과 프론트 엔드 팀 간의 독립성을 높일 수 있습니다.

WordPress를 발전시키는 또 다른 도구 세트입니다. 그리고 우리가있는 곳으로 가려면 구불 구불 한 여행 이었지만 시간을내어 탐험하고 이해하는 것이 좋습니다.


1

가장 먼저해야 할 것-REST는 가벼움

한 줄로-REST API를 사용할 때 클라이언트 측 (루프, 조건 및 서버 측 호출 등)에서 모든 데이터 렌더링을 수행하여 대역폭을 절약하고 동시에 애플리케이션이 모든 모바일 플랫폼, 타사 통합 및 모듈화 ( 프론트 엔드와 서버 측 간의 우려 분리).

이것을 원하지 않습니까?


0

@Milo가 언급 한 2 가지 장점 외에도 REST API를 사용하여 데이터를 WordPress 이외의 응용 프로그램에 노출시킵니다. Google은 WordPress 데이터베이스에서 정보를 가져 오는 Chrome 확장 프로그램을 보유하고 있으며 POST 요청으로 REST API 엔드 포인트를 실행하면됩니다.


0

일관된 인프라

REST API는 일관되고 사람이 읽을 수 있습니다. 자체 문서화입니다.

GET wp-json/wp/v2/posts그것이 무엇을하는지는 분명합니다. 그것은 GET어떤 게시물이야.

네임 스페이스 : wp, 버전 : v2및 객체 컬렉션이 있습니다.posts

당신은 무엇을 추측 할 수 있습니까 : GET wp-json/wp/v2/posts/5합니까? 어때요?GET wp-json/wp/v2/posts/5/comments 방법 :GET wp-json/shop/v2/orders/345/lines/11/price

개발자는이를 살펴보면 쉽게 추측 할 수 있으며 , 설명서를 읽지 않아도 11주문 가격 을 주문할 345수 있습니다. 개발자 shop는 네임 스페이스에 따라 플러그인 에서 나왔다는 것을 쉽게 알 수 있습니다 .

어때요? POST /wp-json/v2/posts title=New Blog Post 어때요PUT /wp-json/v2/posts title=New Title

꽤 분명합니다. 새로운 게시물을 만듭니다. 그건 그렇고, 그것은 새로운 게시물의 ID를 반환합니다. AJAX 또는 REST API가 아닙니다. AJAX는 단순히 REST API에 액세스 하는 기술입니다 . 이전에는 다음과 같은 추상적 인 아약스 함수 이름이 필요했습니다 get_price_for_lineitem( $order, $line ). 숫자 또는 JSON 객체 만 반환합니까? 잘 모르겠습니다. 문서는 어디에 있습니까? 아 ... 아약스 호출이었다 get_order_line_price또는get_lineitem_price .

기존 wp-jsonAPI는 자체 엔드 포인트를 생성 할 때 따라야 할 기본 모델 을 제공 하기 때문에 개발자는 이러한 결정을 내릴 필요가 없습니다 . 물론 플러그인 또는 API 개발자는 이러한 규칙을 위반할 수 있지만 일반적으로 이미 설정된 표준을 따르는 것이 더 쉽고 대부분의 개발자는 이미 설정된 패턴을 따르는 것이 좋습니다 (현재 jQuery 패턴이 얼마나 널리 퍼져 있는지 확인).

방해받지 않는 흡수

POST /wp-json/mysite/v1/widgets title=Foobar작동 방식에 관심 이 있습니까? 아니. 나는 단지 새로운 것을 만들고 싶어 Widget하고 나는 그 대가로 ID를 원한다. 페이지를 새로 고치지 않고 프런트 엔드의 양식에서 수행하고 싶습니다. URL을 요청하면 PHP, C #, ASP.NET 또는 다른 기술인지 상관하지 않습니다. 새 위젯을 만들고 싶습니다.

REST API는 백엔드를 프론트에서 분리합니다. 기술적으로 API가 충분하면 전체 백엔드 스택을 변경할 수 있습니다. 동일한 REST API 구조를 유지하는 한 API에 의존하는 것은 영향을받지 않습니다.

REST API가 단순하고 일관성이 있고 Widgets오브젝트 콜렉션 과 같은 명사를 사용하고 Widget/2단일 엔티티를 나타내는 것과 같은 명사 / 식별자 를 사용하는 경우 다소 기본적인 데이터베이스 배관이므로 API를 매우 다른 기술로 작성하는 것이 매우 간단합니다. 암호.

표준 HTTP 요청 동사를 사용합니다.

REST API는 웹 작동 방식의 핵심과 표준 데이터 CRUD 함수에 맵핑하는 동사 (읽기 : 조치)를 활용합니다.

CREATE : POST
READ   : GET
UPDATE : PUT/PATCH
DELETE : DELETE

더 많은 HTTP 동사가 있지만 이것들은 기본입니다. 인터넷을 통한 모든 단일 요청은이 동사를 사용합니다. REST API는 요청시 웹이 구축 된 모델의 바로 위에 있습니다. 그 사이에 통신 계층이나 추상화 모델이 필요하지 않습니다. URL에 대한 표준 http 요청 일 뿐이며 응답을 반환합니다. 당신은 그것보다 훨씬 간단하게 얻을 수 없습니다.

본질적으로 개발자는 웹이 실제로 어떻게 작동하는지에 대한 기본 사항을 더 잘 알 수 있으며 기본 프로토콜이 어떻게 작동하는지 이해하면 더 효율적으로 더 나은 제품을 만들 수 있습니다.

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