0

Im working on a web service that i want to be RESTful. I know about the CRUD way of doing things, but I have a few things that im not completly clear with. So this is the case:

I have a tracking service that collects some data in the browser (client) and then sends it off to the tracking server. There are 2 cases, one where the profile exists and one where it does not. Finally the service returns some elements that has to be injected to the DOM.

So basically i need 2 web services:

  1. http://mydomain.tld/profiles/
  2. http://mydomain.tld/elements/

Question 1: Right now im only using GET, but im rewriting the server to support CRUD. So in that case i have to use POST if the profile does not exist. Something like http://mydomain.tld/profiles/ and then POST payload have the information to save. If the profile is existing i use PUT and http://mydomain.tld/profiles// and payload of PUT has data to save. All good, but problem is that as far as i understand, xmlhttp does not support PUT. Now is it ok to use POST even though its an update?

Question 2: As said my service returns some elements to be injected into the DOM, when a track is made. Logically, to keep it RESTful, i guess that i would have to use POST/PUT to update the profile and then GET to get the elements to inject. But to save bandwidth and resources on the serverside, it makes more sense to return the elements with the POST/PUT to profiles, even though its a different resource. What are your take on this?

BR/Sune

EDIT:

Question 3: In some cases i only want to update the profile and NOT receive back elements. Could i still use same resource and then using a payload parameter to specify if i want elements, e.g. "dont_receive_elements:true"

sunebrodersen
  • 309
  • 5
  • 16

2 Answers2

0

On question #1, are you sure that xmlhttp does not support "put"? I just ran http://www.mnot.net/javascript/xmlhttprequest/ on three browsers (Chrome, Firefox, IE) and according to the output, "put" was successful on all browsers. Following the information on http://www.slideshare.net/apigee/rest-design-webinar (and I highly recommend checking out the many Apigee videos and slideshows on restful API), "put" is recommended for the use case you mention.

But you may be able to avoid this issue entirely by thinking a little differently about your data. Is it possible to consider that you have a profile and that for each profile you have 0 or more sets of payload information? In this model the two cases are: 1. No profile exists, create profile with a POST on .../profiles/ Then add elements/tracking data with posts to .../profile/123/tracks/ (or .../profile/123/elements/) 2. Profile exists, just add the elements/tracking data

(Sorry without understanding your model in detail, it is hard to be very precise).

As for question #2 - going with a data model where a profile has 0 or more elements, you could update the profile (adding the necessary elements) and then return the updated profile (and its full graph of elements), saving you any additional gets.

More generally on question #2, as the developer of the API you have a fair amount of freedom in the REST world - if you are focused on making it easy and obvious for the consumers of your API then you are probably fine.

Bottom line: Check out www.apigee.com - they know much more than I.

user229044
  • 232,980
  • 40
  • 330
  • 338
Richard Berger
  • 247
  • 2
  • 11
  • thanks for the answer. I will look at the PUT part. Regarding question 2 - my understanding is that in REST world each resource have its own unique uri to be used. In my case i want to save requests to the server by updating/creating one resource and in the same call, actually return another resource. Is that acceptable? The resource im returning could also be GET'ed on its own uri. – sunebrodersen Jul 13 '12 at 07:40
  • Trying to take the perspective of one of your API developers, it would be somewhat unexpected to post to Resource A and then get back Resource B. And anything unexpected would need to be clearly documented and would represent a little bit of a barrier to learning and using your API. So, if you would be taking this approach to save yourself time, then I would NOT do it. If it is a possible performance issue, I would wait until it was a real performance issue because the success of your API is really based on the ability of others to learn it and use it. Hope this helps, RB – Richard Berger Jul 13 '12 at 15:46
  • Please [don't add signatures or taglines to your posts](http://stackoverflow.com/faq#signatures). – user229044 Jul 17 '12 at 03:27
0

@Richard - thanks alot for your links and feedback. The solution i came down to is to make the API simple and clean as you suggest in your comment, having seperate calls to each resouce.

Then to be able to save bandwidth and keep performance up, I made a "non-official" function in the API that works like a proxy internally and are called with a single GET, that updates a profile and returns an element. This, i know, is not very restful etc, but it handles my situation and is not part of the official API. The reason i need it to support GET for this i need to call it from javascript and cross domain.

I guess i could have solved the cross domain by using JSONP, but i would still have to make the API "unclean" :)

sunebrodersen
  • 309
  • 5
  • 16