Deprecating rest.wikimedia.org in favor of /api/rest_v1/

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Deprecating rest.wikimedia.org in favor of /api/rest_v1/

Gabriel Wicke-3
We have decided to officially retire the rest.wikimedia.org domain in
favor of /api/rest_v1/ at each individual project domain. For example,


  https://rest.wikimedia.org/en.wikipedia.org/v1/?doc

becomes

  https://en.wikipedia.org/api/rest_v1/?doc

Most clients already use the new path, and benefit from better
performance from geo-distributed caching, no additional DNS lookups,
and sharing of TLS / HTTP2 connections.

We intend to shut down the rest.wikimedia.org entry point around
March, so please adjust your clients to use /api/rest_v1/ soon.

Thank you for your cooperation,

Gabriel

--
Gabriel Wicke
Principal Engineer, Wikimedia Foundation

_______________________________________________
Mediawiki-api mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
Reply | Threaded
Open this post in threaded view
|

Re: [Wikitech-l] Deprecating rest.wikimedia.org in favor of /api/rest_v1/

Gabriel Wicke-3
Strainu,

On Mon, Jan 25, 2016 at 11:01 AM, Strainu <[hidden email]> wrote:
> Hi,
>
> Does this apply to the Graph extension as well?

the graph extension has been using /api/rest_v1/ right from the start,
so it's likely that no changes are needed for graphs.

Gabriel

_______________________________________________
Mediawiki-api mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
Reply | Threaded
Open this post in threaded view
|

Re: [Engineering] [Wikitech-l] Deprecating rest.wikimedia.org in favor of /api/rest_v1/

Gabriel Wicke-3
On Mon, Jan 25, 2016 at 11:38 AM, Oliver Keyes <[hidden email]> wrote:
> Will it apply to the pageviews API as well?

It will, but the canonical URL for this has always been
https://wikimedia.org/api/rest_v1/?doc, which will continue to work.
Are you aware of any pageview users hitting rest.wikimedia.org?

In any case, we'll check the logs for remaining rest.wikimedia.org
accesses & make an effort to remind remaining users before
decommissioning it.

Gabriel

_______________________________________________
Mediawiki-api mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
Reply | Threaded
Open this post in threaded view
|

Re: [Engineering] [Wikitech-l] Deprecating rest.wikimedia.org in favor of /api/rest_v1/

XDiscovery Team
Hello,

I was not aware api.wikipedia are available in cached version !

I tried /rest_v1/ endpoint and it is terribly fast.
@Strainu / @Gabriel , what does  'graph' extension do ?


I have few questions for using proxy cache:
1# Is it possible to query a page by page_ID and include redirect?

/page/title/{title}
allow to get metadata by page, including the pageID , but I would like to have final page redirect (e.g. dna return 7956 and I would like to fetch 7955 of redirected 'DNA' )
/page/html/{title} get the article but page_ID / curid is missing in source

I would like to get the two combined.

2# The rest are experimental:
what could happen if a query fail?
Does it raise an error, return 404 page or what else?
I am thinking if possible to use api.wikipedia as fallback, and use proxy cache as primary source any ajax example for doing that to handle possible failures?

3# Does /rest/ endpoint exist also for other languages?











On Mon, Jan 25, 2016 at 10:13 PM, Gabriel Wicke <[hidden email]> wrote:
On Mon, Jan 25, 2016 at 11:38 AM, Oliver Keyes <[hidden email]> wrote:
> Will it apply to the pageviews API as well?

It will, but the canonical URL for this has always been
https://wikimedia.org/api/rest_v1/?doc, which will continue to work.
Are you aware of any pageview users hitting rest.wikimedia.org?

In any case, we'll check the logs for remaining rest.wikimedia.org
accesses & make an effort to remind remaining users before
decommissioning it.

Gabriel

_______________________________________________
Mediawiki-api mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api



--
Luigi Assom
Founder & CEO @ XDiscovery - Crazy on Human Knowledge
Corporate
www.xdiscovery.com
Mobile App for knowledge Discovery
APP STORE  | PR  | WEB 

T +39 349 3033334 | +1 415 707 9684

_______________________________________________
Mediawiki-api mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
Reply | Threaded
Open this post in threaded view
|

Re: [Engineering] [Wikitech-l] Deprecating rest.wikimedia.org in favor of /api/rest_v1/

Gabriel Wicke-3
Luigi,

On Thu, Jan 28, 2016 at 2:09 AM, XDiscovery Team <[hidden email]> wrote:
> I tried /rest_v1/ endpoint and it is terribly fast.

that is great to hear. A major goal is indeed to provide high volume
and low latency access to our content.

> @Strainu / @Gabriel , what does  'graph' extension do ?

If you refer to
https://en.wikipedia.org/api/rest_v1/?doc#!/Page_content/get_page_graph_png_title_revision_graph_id,
this is an end point exposing rendered graph images for
https://www.mediawiki.org/wiki/Extension:Graph (as linked in the end
point documentation).

> I have few questions for using proxy cache:
> 1# Is it possible to query a page by page_ID and include redirect?

We don't currently provide access by page ID. Could you describe your
use case a bit to help us understand how access by page id would help
you?

> /page/title/{title}
> allow to get metadata by page, including the pageID , but I would like to
> have final page redirect (e.g. dna return 7956 and I would like to fetch
> 7955 of redirected 'DNA' )

We are looking into improving our support for redirects:
https://phabricator.wikimedia.org/T118548. Your input on this topic
would be much appreciated.

> /page/html/{title} get the article but page_ID / curid is missing in source
> I would like to get the two combined.

This information is actually included in the response, both in the
`ETag` header and in the <head> of the HTML itself. I have updated the
documentation to spell this out more clearly in [1]. The relevant
addition is this:

The response provides an `ETag` header indicating the revision and
render timeuuid separated by a slash (ex: `ETag:
701384379/154d7bca-c264-11e5-8c2f-1b51b33b59fc`). This ETag can be
passed to the HTML save end point (as `base_etag` POST parameter), and
can also be used to retrieve the exact corresponding data-parsoid
metadata, by requesting the specific `revision` and `tid` indicated by
the `ETag`.

> 2# The rest are experimental:
> what could happen if a query fail?
> Does it raise an error, return 404 page or what else?

The stability markers are primarily about request and response
formats, and not about technical availability. Experimental end points
can change at any time, which can result in errors (if the request
interface changed), or return a different response format.

We are currently discussing the use of `Accept` headers for response
format versioning at
https://www.mediawiki.org/wiki/Talk:API_versioning. This will allow us
to more aggressively stabilize end points by giving us the option of
tweaking response formats without breaking existing clients.

> I am thinking if possible to use api.wikipedia as fallback, and use proxy
> cache as primary source any ajax example for doing that to handle possible
> failures?

Yes, this is certainly possible. However, you can rely on end points
currently marked as "unstable" in the REST API. Basically all of them
are used by a lot of production clients at this point, and are very
reliable. Once we introduce general `Accept` support, basically all of
the unstable end points will likely become officially "stable", and
several `experimental` end points will graduate to `unstable`.

> 3# Does /rest/ endpoint exist also for other languages?

Yes, it is available for all 800+ public Wikimedia projects at /api/rest_v1/.


[1]: https://github.com/wikimedia/restbase/pull/488/files#diff-2b6b60416eaafdf0ab45f6c9ffb8be3aR225

--
Gabriel Wicke
Principal Engineer, Wikimedia Foundation

_______________________________________________
Mediawiki-api mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
Reply | Threaded
Open this post in threaded view
|

Re: [Wikitext-l] [Engineering] [Wikitech-l] Deprecating rest.wikimedia.org in favor of /api/rest_v1/

Gabriel Wicke-3
Hi Luigi,

On Fri, Jan 29, 2016 at 12:31 PM, Luigi Assom <[hidden email]> wrote:
> -  how to extract _ID from ETag in headers:
> GET /page/title/{title}

the page id is indeed not directly exposed in the HTML response.
However, the revision number is exposed as part of the ETag. This can
then be used to request revision metadata including the page id at
https://en.wikipedia.org/api/rest_v1/?doc#!/Page_content/get_page_revision_revision.
This is admittedly not very convenient, so I created
https://phabricator.wikimedia.org/T125453 for generally improved page
id support in the REST API.

> - how to ensure
> GET /page/title/{title with different char encoding or old titles are always
> resolved to last canonical version}

The storage backing this end point is automatically kept up to date
with edits and dependency changes. Edits in particular should be
reflected within a few seconds.

>> If you refer to
>>
>> https://en.wikipedia.org/api/rest_v1/?doc#!/Page_content/get_page_graph_png_title_revision_graph_id,
>> this is an end point exposing rendered graph images for
>> https://www.mediawiki.org/wiki/Extension:Graph (as linked in the end
>> point documentation).
>
>
> Oh very interesting!
> So basically html markup can be extended ?
> Would it be possible to share json objects as html5 markup and embed them in
> wiki pages?

The graph extension is using the regular MediaWiki tag extension
mechanism: https://www.mediawiki.org/wiki/Manual:Tag_extensions

Graphs are indeed defined using JSON within this tag.

> I want to avoid to update my graph just because titles changes: entities are
> always the same.

Makes sense. The current API is optimized for the common case of
access by title, but we will consider adding access by page ID as
well.

> I still don't know what parsoid is.

Parsoid is the service providing semantic HTML and a bi-directional
conversion between that & wikitext:
https://www.mediawiki.org/wiki/Parsoid

Gabriel

_______________________________________________
Mediawiki-api mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
Reply | Threaded
Open this post in threaded view
|

Re: [Mediawiki-api-announce] Deprecating rest.wikimedia.org in favor of /api/rest_v1/

Gabriel Wicke-3
In reply to this post by Gabriel Wicke-3
Final reminder on this: We are planning to finally sunset
rest.wikimedia.org in the week starting April 25th, 1 1/2 weeks from
now. Please move your REST API clients to /api/rest_v1/ at the regular
project domains instead!

Thanks,

Gabriel

On Mon, Jan 25, 2016 at 11:00 AM, Gabriel Wicke <[hidden email]> wrote:

> We have decided to officially retire the rest.wikimedia.org domain in
> favor of /api/rest_v1/ at each individual project domain. For example,
>
>
>   https://rest.wikimedia.org/en.wikipedia.org/v1/?doc
>
> becomes
>
>   https://en.wikipedia.org/api/rest_v1/?doc
>
> Most clients already use the new path, and benefit from better
> performance from geo-distributed caching, no additional DNS lookups,
> and sharing of TLS / HTTP2 connections.
>
> We intend to shut down the rest.wikimedia.org entry point around
> March, so please adjust your clients to use /api/rest_v1/ soon.
>
> Thank you for your cooperation,
>
> Gabriel
>
> --
> Gabriel Wicke
> Principal Engineer, Wikimedia Foundation



--
Gabriel Wicke
Principal Engineer, Wikimedia Foundation

_______________________________________________
Mediawiki-api-announce mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
_______________________________________________
Mediawiki-api mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
Reply | Threaded
Open this post in threaded view
|

Re: [Engineering] Deprecating rest.wikimedia.org in favor of /api/rest_v1/

Marko Obrovac
Hello,

On 15 April 2016 at 01:04, Gabriel Wicke <[hidden email]> wrote:
Final reminder on this: We are planning to finally sunset
rest.wikimedia.org in the week starting April 25th, 1 1/2 weeks from
now. Please move your REST API clients to /api/rest_v1/ at the regular
project domains instead!

This will happen in a week's time. We are, however, still observing quite a volume of requests for mobile sections endpoints using the rest.wikimedia.org domain. Specifically, almost all of the requests are asking for resources pertaining to the de.wikipedia.org domain. Unfortunately no user-agent header is provided so we are not able to pin-point the client. Please ensure your clients point to https://{domain}/api/rest_v1/ instead of <a href="https://rest.wikimedia.org/{domain}/v1/">https://rest.wikimedia.org/{domain}/v1/.

Cheers,
Marko
 

Thanks,

Gabriel

On Mon, Jan 25, 2016 at 11:00 AM, Gabriel Wicke <[hidden email]> wrote:
> We have decided to officially retire the rest.wikimedia.org domain in
> favor of /api/rest_v1/ at each individual project domain. For example,
>
>
>   https://rest.wikimedia.org/en.wikipedia.org/v1/?doc
>
> becomes
>
>   https://en.wikipedia.org/api/rest_v1/?doc
>
> Most clients already use the new path, and benefit from better
> performance from geo-distributed caching, no additional DNS lookups,
> and sharing of TLS / HTTP2 connections.
>
> We intend to shut down the rest.wikimedia.org entry point around
> March, so please adjust your clients to use /api/rest_v1/ soon.
>
> Thank you for your cooperation,
>
> Gabriel
>
> --
> Gabriel Wicke
> Principal Engineer, Wikimedia Foundation



--
Gabriel Wicke
Principal Engineer, Wikimedia Foundation

_______________________________________________
Engineering mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/engineering



--
Marko Obrovac, PhD
Senior Services Engineer
Wikimedia Foundation

_______________________________________________
Mediawiki-api mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api