Hacker News Reader

Comment by peterwwillis | Hacker News Reader

So let's say there's a resource that you want to update, but you don't know if it exists or not. Either you can GET (or HEAD or something) to see if it exists and then PUT if it exists or POST if it doesn't exist yet. Or you can just have PUT create and/or update it whether or not it exists, skipping the requirement of knowing whether you need to create it or not. (Or did I miss something?)

View on HN

You are one step ahead though. How can you address a resource if you don't know beforehand the representation of its identifier? Say, you want to create a new Employee under /Employees. Do you just issue a 'GET /Employees/1234' and assume '1234' is a valid identifier when you get a 404? What if the system expects a MongoDB _id such as '47cc67093475061e3d95369d'?

A workaround, as was suggested by an other poster, is that the client interrogates the system for a valid identifier and then proceeds. This especially makes sense when, as noted, you are dealing with resources that belong to no collection.

All these are good points.

However, in the case where the Id is the nature key (e.g. SSN), the Id can be known from the user input. Creating an employee is just a matter of PUT his full record along with his SSN as the Id.

Save yourself some hassle. Don't key on SSN.

1) Encryption (and then indexing) becomes harder.

2) SSN's can change, for many reasons. (eg: http://consumerist.com/2008/11/can-i-change-my-social-securi..., data entry error, etc)

It is a bad idea to use anything entered by a user as the primary key.

It is ok to use data entered by users to assure the uniqueness of a record (unique indexes/constraints).

The client shouldn't know how to assemble URLs. The better way to do this is to POST to /Employees and have the server return the URL of the newly-created employee.

Assuming the request is valid, PUT should work without regard to whether the resource existed already. You're asserting what should be there, and if it works, then it either creates it or overwrites what was there before.

You have to use PUT to enable creating something only when the server URL that the resource will be available at is not known to the client.

Is 404 not a valid return for a PUT?

And I assume you mean POST for paragraph 2?

I wouldn't think that 404 makes any sense for PUT, no. Similarly, "410 Gone" would be a confusing result, at least.

I did mean "POST" in paragraph 2, yes. Thanks. :)

Reply on news.ycombinator.com