Ability to version a resource

In services_get_updates do we want a real cache as well as a static cache? - otherwise looks sensible as it does what core does with its updates :)

In services_get_update_versions I don't like the use of

extract($update);

bit too 'magic' I would rather we did, I haven't updated this until we discusss

$value = $update['major'] .'.'. $update['minor'];

Do we want to add an option at the server level to disable versioning have added - not sure the best way to deal with it when we are in _services_build_resources - I think this important so as sites aren't forced to run versioning (maybe we make the variable global which would simplify things.)

  if (variable_get('services_rest_service_versioning_enabled', TRUE) {

I can't think of a better way to do the actual version call because of where it needs to happen? No matter what a server is going to need to add a new call to get versioning.

Again in services_request_apply_version can we avoid extract?

In services_request_apply_version if this is true can we stop processing so throw the rest in an if statement?

if (isset($version) && $version == '1.0') {
  $controller = $controller['original'];
}

New patch attached.

can't see a syntax issue locally.

This should fix all exception simplification of Kyle's change

And some other notices

Check if we have a $method before processing.

Adding needs tests tag because it does.

So the method does exist - bit wtf, lets try changing the assert which is strange in the first place as the logic is reversed.

Will my example module work with this patch (no API changes right?)? I hope to try it out sometime this weekend.

boombatower's example module may well be the way to go as a basis for a test :) We know that it should work therefore if we have a test then we should be able to spot the bugs.

-    $resource['endpoint'] = $cres;
+    $resource['settings'] = $cres;

This is an API change (and a significant one). It broke a couple of things in Services itself:

    foreach ($resources as $key => $def) {
      if (!empty($def['endpoint']['alias'])) {
        $aliased[$def['endpoint']['alias']] = $def;
      }
      else {
        $aliased[$key] = $def;
      }
    }

^ The alias feature doesn't work at all anymore.

  if (isset($method['endpoint']['services_oauth'])) {
    $endpoint += array_filter($method['endpoint']['services_oauth']);
  }

^ I haven't tested, but I suppose it completely broke per-resource oauth settings too?

This is a revert patch, just so that I can target it in a make file.

I think this patch should be reverted until its impact in terms of API change are figured out. Changing a datastructure that can be consumed or altered by other modules inside a stable is an API change that is not welcome in a stable branch.

After Damien's comment I am wondering if this patch should be reverted and a 4.x branch opened with this patch applied. I am not doing anything myself as I not really active as a maintainer on the services project at the moment beyond reviewing simple patches and bug reports due to lack of time.

ServicesWebTestCase::setUp argument handling changed in this patch as well. Darn. Now it will be a bit more difficult to sub class my sub class of that and pass in modules to enable.

I can create a different issue so that it's separate from this one. I wasn't sure how critical the change to setUp was.

Here is the patch that reverts

-    $resource['endpoint'] = $cres;
+    $resource['settings'] = $cres;

and adds test for alias functionality.

kylebrowning, you are right. I also have difficulties with ui. Will check it out.

Well done! Here is patch from #47 with some minor code style fixes. If tests pass it is RTBC to me.

+ *  Update the current user logout callback to the new callback with a better return value.
+ */
+function _user_resource_logout_update_1_1() {

Missing empty line.

Also does this patch solve the issue original brought up by damz

Yes, patch solves issue brought by Damien.

Here is updated patch to add empty line.

Woo-hooo! Great commit Kyle!

I don't want to volunteer to backport this patch.

Dropped completely or what do you mean by dropped?

I thought you meant the historical api was going to be dropped from a 8.x services.