Question on Restangular and PUT request

[thomasmktong]

I have a question about the way that this project handles PUT requests, and I would like to have your input on whether we should / how to refactor the codes, thanks.

The standard restful PUT request should be sent like this:

PUT /api/roles/1

where 1 is the ID of the object to update. However, the front end of this project sends the PUT request like this:

PUT /api/roles

and then back end takes the object in request payload to update the one in DB. So in this case it works fine, but if I define resource like this in routes.php

$api->resource('vacancies', 'VacancyController');

the PUT requests without ID won't work. Back end only takes the one with ID because that is how PUT should be coded. I did some investigation on why Restangular in this project behaves like this, and it is related to how back end responded the original GET request:

{"errors":false,"data":{"id":2, "xxx": "xxxxxxx"}}

the data object is wrapped inside so Restangular is unable to get the data ID, and also when the PUT request is sent, this whole thing including {"errors":false, ... is included in the PUT request - while it should be just the data object.

I would like to seek you guys' opinions on whether this should be changed, and if needed, which way we should do. I am happy to submit PR for this.

• Option 1: In API.service.js, add logic in addResponseInterceptor to return only the data object inside (if no error), but this may add difficulties when we need to handle things like pagination
• Option 2: Update Restangular.configuration.getIdFromElem to get the ID correctly. In this case the {"errors":false, ... parts are still sent back during PUT requests
• Option 3: Not to make any changes

Thanks.

[silverbux]

actually what i liked about the current is that you could simply put the returned object in an instance and simply do a this.role.put() which is all being handled by restangular, that i think save coding time and make things simpler, i think that was the reason i gave up the api/roles/1 standards. specially PUT is the verb being used and its being done on a background (ajax) anyway. also another disadvantage is that you get ugly remote method name like for this example putRolesShow