Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.I decided to do an initial porting of this module to Services since I think we can all benefit from cooperation. I know there's some shortcomings in the port - I just wanted to do it as a proof that Services is able to provide the result you're looking for. Lets work together on ironing out the shortcomings.
You can find a patch here: https://github.com/voxpelli/restws/commit/ee1745a72a2c86fc8895778b4779c7...
And a pull request here: https://github.com/klausi/restws/pull/1
With the latest patch here: https://github.com/klausi/restws/pull/1.diff
Comments
Comment #1
klausiWow, I'm impressed. Thank you! Will test that in the next days and come back to you. I'd like to keep the simpletests and the restws_base_auth module though.
Comment #2
klausiTook a closer look now. I tried to run the simpletests (you can find the code I used in the services-port branch), but not even the GET request works out (however, it works in my browser). So before we continue anything here I would like to have working simpletests along the way.
Some other concerns:
* This approach duplicates resources in an inconsistent way. A node in the restws context looks slightly different than a default node resource from services.
* As you can see we return other resource reference information on the create operation. We like to have the plain ID, the URI and the resource type.
* Services is a lot of code, a big module. For our use case it seems to be really heavy weight and does not offer much benefit.
* The Entity API with its property information is one of the crucial parts in restws that is used to describe resources. Wrappers help in saving incomming data, so that would make a lot of resource definitions in services obsolete.
* Endpoints: why should the same resource live at multiple endpoints? I know, we already discussed the authentication problem in #1042512: Why not use Services Module?, but I think it is very important that authentication is completely transparent.
So at the moment I'd like to keep restws a standalone module, as there are too many open questions how services and restws can be combined. However, I appreciate your work and am open to further patches and ideas.
Comment #3
gddMy (only) comments are here for reference
http://drupal.org/node/1042512#comment-4027582
Comment #4
voxpelli commentedHad forgotten to adjust the info file. Now did and some of the tests are working now. The ones which fails now are probably due to the port not being completed.
1. Yes this duplicates resources in an inconsistent way but I don't think it's a big deal. Services provides some building blocks for API:s but I think that if any other module can provide better resources then they should do so and we can make them part of an upcoming Services version. And no matter if RestWS is based on Services or not it will duplicate the resources - the question is whether it will duplicate the rest ;)
2. Doesn't my port return the same data as your original module does? I thought it did. If not then I must have missed something. What should I change?
3. Well - Views and Drupal in itself is a lot of code also - but it's what makes them powerful. I wouldn't be too worried about it but any suggestions on how to make it smaller is welcome. I don't think there's anything removable right now without angering somebody (although we have already removed two parts a bit too close to stable release :P)
4. Obsoleting some of the building blocks of Services is no problem. The Services OAuth module did the same to the Key auth module in Services 2.x and has therefor replaced it in Services 3.x. It's how opensource evolves. Third party modules can most of the time evolve more rapidly than the core system and can therefor test stuff that the core system is unable to.
5. Resources are building blocks that the endpoints combines with servers, authentication mechanisms and similar to create an API. Since resources are independent from the endpoints they can be used across many endpoints. In the case of Services you might eg. want to have an XML-RPC API with session authentication in parallell with a REST API and they would need two different endpoints - eg. Flickr does that. No one forces you to reuse resources - but it's possible for the cases when it is useful :)
I agree that restws should be a separate module. But I think it would be a waste of resources to not work together on the parts we agree on.
Comment #5
geerlingguy commentedSub.
Comment #6
fago>I agree that restws should be a separate module. But I think it would be a waste of resources to not work together on the parts we agree on.
I could say providing resources without the entity API and thus doing all the CRUD stuff again is duplicating efforts too.
The point is, both modules have different goals (REST vs all) and different design decisions, so as already explained in #745046-12: make use of entity metadata, this won't happen now. Thanks a lot for your engagement though!
Comment #7
kylebrowning commentedIN this post, and the previous post you have failed to explain how the goals are different.
Im completely shocked at the level of ego going on right now.
Comment #8
voxpelli commentedI will not do any more work on this as it's a waste of time. I've proven that RestWS could technically use Services to accomplish its goals, but the maintainers still insists on not doing so due to unknown "design decisions" and "goals". People can draw their own conclusions from that - I've drawn mine.
Comment #9
klausiThe design decisions are well known, as explained in the README, on the project page or in various issue comments (#1042512-2: Why not use Services Module?, #1042512-4: Why not use Services Module?, #1042512-8: Why not use Services Module?, #1044162-2: Move to Services, initial port)
If there is still anything unclear, just ask. I leave this issue open, maybe other people want to work on this patch.
Comment #10
dgtlmoon commentedwow, epic head butting going on