0

Need some suggestions for the following queries:

  1. If client wants to access a particular resource, for eg: http://sample.com/user/id/profile. Then in this case how to store id on the client side.

  2. Is cookie is the solution for the above question, if yes, then what will happen in the case when cookie is disabled?

  3. How to use HTTP methods PUT and DELETE? As, HTML does not support it.

Can you guys suggest any reference material for designing RESTful webservices with Spring?

Thanks

Touchstone
  • 5,575
  • 7
  • 41
  • 48
  • 1. You don't store the Id as it is already in the URL, why store it (so 2 doesn't apply). 3. Use javascript, in general when writing a REST api this is used in conjunction with JavaScript which does support other method then only GET/POST. Else use POST instead of PUT/DELETE. – M. Deinum Feb 10 '14 at 07:06
  • Thanks!! I have a little doubt. http://sample.com/user/id/profile will contain user specific id values. For eg: for user with user_id =1 the url will be http://sample.com/user/1/profile and for user with id=2 the url will be http://sample.com/user/2/profile and so on. so, how will one create a dynamic url without storing the ID values? – Touchstone Feb 10 '14 at 07:24

2 Answers2

0

The ID is intrinsic in the URL, but the document you deliver can also contain the ID for convenience. You didn't mention what Content-Type you're serving, but assuming it's XML or JSON, you can stick an ID attribute in. Even better, the client should be addressing by the URL rather than the ID. This is where the HATEOAS principle comes in: serve a document with links to other documents and navigate the documents the way you'd navigate web pages. It's common practice to paste together URLs from well known components, but it's better to say the URL of the entity is its id. The mantra where I work is "don't attempt to reason about URLs", meaning clients are not supposed to parse a URL from our API, they're supposed to treat it as an opaque object. So when you talk about "creating a dynamic URL", don't do that. You can discover resources thru a search URL, such as /user/findByEmail?email=foo@example.com, which will return a collection of User entities that match that email.

You shouldn't need to rely on cookies for anything in a RESTful solution. Sometimes they're convenient, for the same reason it's convenient in a regular website, but you don't NEED cookies. If this is a real REST API, you need to remember that cookies can entail extra work for the client. Just because the web browser magically handles them doesn't mean someone writing a client in C#, Java, PHP, Ruby, whatever other language, has the magic cookie support baked in. Standard HTTP, however, is pretty universal.

HTML Forms don't support PUT & DELETE, though most people are accessing REST APIs through Javascript these days. If you absolutely have to support HTML forms without Javascript, you can overload actions onto POST - i.e. if your resource is /user/id/profile, then POST an empty document to /user/id/profile/delete or /user/id/profile/update. This isn't great practice, but if you have to, you have to.

Gordon
  • 321
  • 1
  • 5
0

Iam not sure if you got the answer to the question. Below is what i think:

If client wants to access a particular resource, for eg: http://sample.com/user/id/profile. Then in this case how to store id on the client side.

  • ANS: Try your clients (i assume its a browser like Chrome) local storage to save the ID

.

Is cookie is the solution for the above question, if yes, then what will happen in the case when cookie is disabled?

  • ANS : see the answer above,

How to use HTTP methods PUT and DELETE? As, HTML does not support it.

  • ANS: not sure of the question.
Albert Pinto
  • 392
  • 2
  • 6
  • 17