[go: nahoru, domu]

Page MenuHomePhabricator

Hard deprecate VirtualRESTService
Closed, ResolvedPublic

Description

  • Affected components: MediaWiki core (VirtualRESTService, libs/virtualrest) and thus VisualEditor, Citoid, Math, Flow, ContentTranslation, Collection, and other non-Wikimedia production extensions.
  • Engineer for initial implementation: TBD.
  • Code steward: TBD.

Motivation

VirtualRESTService was introduced to encourage the internal use of HTTP services. This is similar to the older mechanism for internal calls to the web API, which now have been deprecated by T169266: Clarify recommendations around using FauxRequest.

Since using VirtualRESTService has the same fundamental problems as using FauxRequest, it should also be deprecated and phased out. This should be simple enough, since it has never seen wide spread use.[citation needed]

Requirements

The interface between PHP code and a configurable service (e.g. one that can be in-process or over HTTP), should take the form of a service class obtained via MediaWikiServices.


Exploration

Note that VirtualRESTServiceClient (or a class with a similar interface) may still be useful for accessing the specific service known as RESTBase from inside MediaWiki. The intention of this RFC is to remove the generic framework for exposing internal services via VirtualRESTServiceClient. Instead, those would use the native approach of a service locator like MediaWikiServices, without pseudo urls and path/query strings.

Related classes of which the faith is to be determined:

  • class VirtualRESTServiceClient
  • abstract class VirtualRESTService
    • class RestbaseVirtualRESTService extends VirtualRESTService
    • class SwiftVirtualRESTService extends VirtualRESTService
    • class ParsoidVirtualRESTService extends VirtualRESTService
    • class ElectronVirtualRestService extends VirtualRESTService

RfC for creating the service

https://www.mediawiki.org/wiki/Requests_for_comment/PHP_Virtual_REST_Service - PHP Virtual REST Service

T112553: Integrate the Virtual Rest Service (VRS) into core, and make it generally available (from RequestContext?)

Related Objects

Event Timeline

Krinkle updated the task description. (Show Details)
Krinkle moved this task from Old to P2: Resource on the TechCom-RFC board.
Krinkle subscribed.

This was created to serve RESTBase and other programs from the former services team. Tagging PE for visibility and to confirm what they are indeed comfortable making a product decision over whether this is needed, and how we might decommision it.

Krinkle changed the task status from Open to Stalled.Sep 18 2020, 3:02 AM
Krinkle triaged this task as Medium priority.
Krinkle moved this task from Untriaged to Not yet on the Technical-Debt (Deprecation process) board.

A quick search turns up usages of RestbaseVirtualRestService and ParsoidVistualRest service. The rest seems unused and can perhaps just be deleted. Here'S the search I did: https://codesearch.wmcloud.org/search/?q=%5Cw%2BVirtualRESTService%5Cb&i=nope&files=&excludeFiles=&repos=

The way forwards seems to be to just have a RestbaseClient and a ParsoidClient class. Though the latter may not be needed since we have Parsoid in core now.

daniel renamed this task from RFC: deprecate VirtualRESTService to Deprecate VirtualRESTService.Jan 28 2021, 9:26 PM
daniel edited projects, added RESTBase; removed TechCom-RFC.

Moving to roadmapping backlog. This looks like for to six weeks of work for a couple of engineers.

DAlangi_WMF changed the task status from Stalled to In Progress.Jun 5 2023, 8:14 AM
DAlangi_WMF changed the status of subtask T337223: Replace usage of VirtualRESTServiceClient in Flow extension from Open to In Progress.
DAlangi_WMF changed the status of subtask T334842: Replace usage of VirtualRESTServiceClient in Math extension from Open to In Progress.

This can be active again as we've been migrating several MediaWiki extensions from no longer using the VirtualRESTService class. So far, we've done Math & Collection. We are still dealing with Flow, it's a WIP.

Is the following summary of the status correct?

  • VRS is now soft-deprecated, but not yet hard deprecated
  • We have to wait with hard deprecation until we have switched VE and ContentTranslation to "direct" mode in production (which is due to happen soon)

Is the following summary of the status correct?

  • VRS is now soft-deprecated, but not yet hard deprecated
  • We have to wait with hard deprecation until we have switched VE and ContentTranslation to "direct" mode in production (which is due to happen soon)

Yes, the status is correct!

DAlangi_WMF renamed this task from Deprecate VirtualRESTService to Hard deprecate VirtualRESTService.Jul 1 2023, 6:11 PM

Change 936659 had a related patch set uploaded (by D3r1ck01; author: Derick Alangi):

[mediawiki/core@master] virtualrest: Hard deprecate VirtualRESTService

https://gerrit.wikimedia.org/r/936659

DAlangi_WMF changed the status of subtask T339227: Remove VRS code from VisualEditor from Open to In Progress.

Change 936659 merged by jenkins-bot:

[mediawiki/core@master] virtualrest: Hard deprecate VirtualRESTService & VirtualRESTServiceClient

https://gerrit.wikimedia.org/r/936659