I would like to propose to remove relationships and targeted actions completely.

Reasons for that are following:
1. Both relationships and targeted actions can be achieved by actions. Only we will need to provide is to make actions to be called with GET. For this I propose to add key to action 'method' where GET, POST, PUT or DELETE can be provided. So devs would be able to create action that will behave like relationship or targeted action.
2. Relationships and targeted actions do not make sense in case we develop for XMLRPC or SOAP.

I think if we will remove them it will simplify the code a lot.

Please share your opinions.

Comments

voxpelli’s picture

voxpelli commented

I oppose this - I think relationships and targeted actions add much needed semantics to Services. It makes Services much more powerful by giving servers much better information on how resources can be exposed. Separating read-only resources from read-write resources is crucial to build secure flexible servers.

1. This ties the resource descriptions too closely to specific server implementations.

2. It's true that these protocols handles everything like actions - they are unable to take advantage of read-only methods.

I would instead like to go in the opposite direction and complete #1042674: Add non-targeted relationships.

gdd’s picture

gdd
he/him
Primary language English
Location Portland, OR
commented

My feeling at this point is that it is too late to be doing any major rearchitecture of Services right now, and we should focus on getting the release out the door. We have already had at least three API changes since the RC, and I am reluctant to add any more. I may even postpone the patch I wrote for comment/node relationships just to get things finished. Let's push decisions like this into the next version (and I thing #1042674: Add non-targeted relationships should remain postponed as well.)

Hugo Wetterberg’s picture

Hugo Wetterberg commented

Services has gone from being RPC oriented to being resource oriented, this means that even though the RPC-servers still are fully supported they're no longer the design template for services. Thus features don't have to make sense for XMLRPC & SOAP, they just mustn't break them. The resource semantics isn't necessary for RPC-style servers, though they too could use them to decide if a method should be accessible via GET or POST.

Hugo Wetterberg’s picture

Hugo Wetterberg commented
Status: Active » Closed (won't fix)