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:

https://github.com/interagent/http-api-design

>Are you more interested in discovery of internal services or external API end 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.

>> 7.Code generation from service api descriptor

Client generation that can be used for both, see for example: https://github.com/interagent/heroics

On Thu, Jun 12, 2014 at 10:28 PM, Gabriel Wicke <gwicke@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_versioning

https://www.mediawiki.org/wiki/Services/Roadmap#Drive_automated_service_testing

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