Perhaps in the example you quoted "services" or "serviceProviders" is not needed.
I tend to use the general pattern of:
<server context>/<application context>/<resource kind>/<system assigned identifier, stable>
So you'd expect:
h t t p://HOST/OSLC4JBugzilla/serviceProviders
Doing a GET on this URL returns all serviceProviders. Doing a POST on this URL, with serviceProvider representation, creates a new serviceProvider
Unless of course, the bugs for your bug tracking tool are scoped only to a project or service provider, then I'd define it a little different.
Just a reminder we are talking about service provider implementation. How best to design the URL space the application will fill. Clients should still use the "follow their nose" approach to discovering resources of interest and not understand this URL construction design and build URLs to try to locate resources of interest.
Perhaps we should consider opening a bug against our reference implementation and make it a slightly better example of these things (what one would really do in a real implementation)
will make move of a bug between service providers problematic as its url = unique identifier will change. Maybe not envisioned in that example, but agree it makes sense adding a bug on this for the ref implementations. Created https://bugs.eclipse.org/bugs/show_bug.cgi?id=423711 - please update if it can be better worded.