I will do my best to try to take a look at the docs you sent and add
comments where it pertains.
We are aiming for more REST and less RPC. We'll
start with JSON and HTML
resources, but could consider other representations later.
I see, in case you did not see it the heroku guys jus released a very
useful set of guidelines for rest apis. The most interesting bit is
pagination, I think:
points?
Not discovery but rather configuration, so I can test serviceX locally in
vagrant and also deploy the client in prod and client has access to the
production configuration. In our case probably we resolve this with puppet
as it seems to be the mother of all things at wikimedia.
On Thu, Jun 12, 2014 at 10:28 PM, Gabriel Wicke <gwicke(a)wikimedia.org>
wrote:
Hi Nuria!
On 06/12/2014 09:53 AM, Nuria Ruiz wrote:
Hello,
I came kind of late to this discussion so you guys might have already
talked about this, please ignore if that is the case.
Much of this has been discussed before, but I'm happy to give you pointers.
I see that in the goals page there is a bunch of
work regarding current
projects but there is little mentioning of the 'background work' needed
to
deploy services. It seems that the work of
building the infrastructure
should be called out explicitly.
I think some of that is already called out. We see it very much as one of
our responsibilities to improve practices across services. We also already
have some experience with production services like Parsoid, so we are not
starting from scratch.
For example:
1. Transport: have we chosen what is it going to be our transport
protocol?
as in json-rpc, protocol buffers...
We are aiming for more REST and less RPC. We'll start with JSON and HTML
resources, but could consider other representations later.
2. Authentication: are services for internal
consumption only (and thus
inside our firewall) or do they provide an authentication scheme?
As stated in the goals, we'll start the first phase with simple internal
authentication, but invest time in a proper solution later on in the
fiscal,
in collaboration with platform. See
https://www.mediawiki.org/wiki/Requests_for_comment/SOA_Authentication.
3. Logging: How would you follow requests across
services, or at least,
follow the jump from client to server?
Matt just set up a GELF sink feeding into logstash. Tracking requests
across
the infrastructure should be possible by including a unique request id in
the structured log information.
4.Versioning
5.Testing (version aware)
https://www.mediawiki.org/wiki/Requests_for_comment/Storage_service#API_ver…
https://www.mediawiki.org/wiki/Services/Roadmap#Drive_automated_service_tes…
Re versioning: I'm leaning towards testing version transformations
separately from the main functionality, as it reduces the number of cases
we
need to cover.
6.Client Configs, how does the client know where
services are?
Are you more interested in discovery of internal services or external API
end points?
7.Code generation from service api descriptor
Are you interested in clients or mocks?
Gabriel