Rails - Jul 2006 - Creating records in two models in a RESTful way.

Hey everyone,

I have a philosophical question here. Say I have a website that uses two 
models for accounts: Person and Company. Normally I would just have 
/accounts/new for user signup.

However, the RESTful way to do it is to have /people and /companies. 
Unfortunately, this doesn''t account for a situation where
you''d have a
one-page signup form. I wouldn''t want this to be a two page process, 
because somebody could close their browser mid-process and that would 
leave me with an incomplete account with only a Company or Person entry. 
How would you all solve this in a RESTful way?

I am strongly considering adopting REST for most of my projects, but I 
can''t decide how I want to solve this.

Regards,

Ray

-- 
Posted via http://www.ruby-forum.com/.

You need to provide data model for clearing your question.

Why not /account ?

On 7/25/06, Raymond Lucke <rails@raylucke.com>
wrote:
> Hey everyone,
>
> I have a philosophical question here. Say I have a website that uses two
> models for accounts: Person and Company. Normally I would just have
> /accounts/new for user signup.
>
> However, the RESTful way to do it is to have /people and /companies.
> Unfortunately, this doesn''t account for a situation where
you''d have a
> one-page signup form. I wouldn''t want this to be a two page
process,
> because somebody could close their browser mid-process and that would
> leave me with an incomplete account with only a Company or Person entry.
> How would you all solve this in a RESTful way?
>
> I am strongly considering adopting REST for most of my projects, but I
> can''t decide how I want to solve this.
>
> Regards,
>
> Ray
>
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

-- 
rm -rf / 2>/dev/null - http://null.in

"Things do not happen. Things are made to happen." - JFK

> I have a philosophical question here. Say I have a website that uses two 
> models for accounts: Person and Company. Normally I would just have 
> /accounts/new for user signup.
I asked DHH this same question on his blog comments - 
http://www.loudthinking.com/arc/000593.html - and he said that an 
additional controller, e.g. signup, with a create action was his own 
solution.

To see his answer, search for "signup" on that page.

Cheers
Nic

-- 
Posted via http://www.ruby-forum.com/.

I''m just wondering.
Are you planning to provide external software to create accounts? Why
are you doing this using REST? It just seems to me like you are making
things more complex and unnatural just because DHH says it''s the way.
Love the guy but I don''t see why adopting REST for everything in every
project can actually lead to better looking code.

On 7/25/06, Raymond Lucke <rails@raylucke.com>
wrote:
> Hey everyone,
>
> I have a philosophical question here. Say I have a website that uses two
> models for accounts: Person and Company. Normally I would just have
> /accounts/new for user signup.
>
> However, the RESTful way to do it is to have /people and /companies.
> Unfortunately, this doesn''t account for a situation where
you''d have a
> one-page signup form. I wouldn''t want this to be a two page
process,
> because somebody could close their browser mid-process and that would
> leave me with an incomplete account with only a Company or Person entry.
> How would you all solve this in a RESTful way?
>
> I am strongly considering adopting REST for most of my projects, but I
> can''t decide how I want to solve this.
>
> Regards,
>
> Ray
>
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

-- 
--------------
Jon Gretar Borgthorsson
http://www.jongretar.net/

> Normally I would just have 
> /accounts/new for user signup.
Thats exactly what rest wants you to do.  Accessing ideas or concepts
with limited verbs is what is important.  If you come up with a concept
that encapsulates a million different tables in your database it would
still be just fine to expose that in a url (have a controller for that
idea).  The only thing you really need to watch out for is crazy verbs.
Not crazy abstract ideas, they''re fine (even encouraged!).  As long as
you don''t stray from the regular list, show, edit, new, etc. actions in
your controllers you are probably doing a good job keeping things
restful.

Thats at least my take.

Raymond Lucke wrote:
> Hey everyone,
> 
> I have a philosophical question here. Say I have a website that uses two 
> models for accounts: Person and Company. Normally I would just have 
> /accounts/new for user signup.
> 
> However, the RESTful way to do it is to have /people and /companies. 
> Unfortunately, this doesn''t account for a situation where
you''d have a
> one-page signup form. I wouldn''t want this to be a two page
process,
> because somebody could close their browser mid-process and that would 
> leave me with an incomplete account with only a Company or Person entry. 
> How would you all solve this in a RESTful way?
> 
> I am strongly considering adopting REST for most of my projects, but I 
> can''t decide how I want to solve this.
> 
> Regards,
> 
> Ray
-- 
Posted via http://www.ruby-forum.com/.

> I''m just wondering.
> Are you planning to provide external software to create accounts? Why
> are you doing this using REST? It just seems to me like you are making
> things more complex and unnatural just because DHH says it''s the
way.
> Love the guy but I don''t see why adopting REST for everything in
every
> project can actually lead to better looking code.
Considering that less code is better looking code, I''d say REST leads
to better
looking code :)


Regards,
Rimantas
--
http://rimantas.com/

On 2006-07-25 08:45:26 -0400, "Rimantas Liubertas" 
<rimantas@gmail.com> said:
>> I''m just wondering.
>> Are you planning to provide external software to create accounts? Why
>> are you doing this using REST? It just seems to me like you are making
>> things more complex and unnatural just because DHH says it''s
the way.
>> Love the guy but I don''t see why adopting REST for everything
in every
>> project can actually lead to better looking code.
> 
> Considering that less code is better looking code, I''d say REST
leads to better
> looking code :)
> 
> 
> Regards,
> Rimantas
I agree that the signup controller will end up using less code. I am 
curious how list resorting fits into this?

I usually have a sort method in my controller that handles it, but 
should I somehow integrate that into my update method?

I don''t think a sort verb is too bad, but I can see how there could end
up being a lot of different variable because of javascript interaction.
-- 

://
Nathan Herald

> I usually have a sort method in my controller that handles it, but
> should I somehow integrate that into my update method?
That''s one aspect of DHH''s CRUD superplan that I
haven''t seen happy
solutions to:

/accounts/14 - returns one Account
/accounts    - returns all Account

* how do you get a subset (search criteria, pagination etc)
* how do you order

Obviously the answer is to add more parameters 
(accounts?sort=name&sort_dir=asc&page=2) but then what have we achieved 
really?

-- 
Posted via http://www.ruby-forum.com/.

It would be great if someone could inform DHH of this thread!

-- 
Posted via http://www.ruby-forum.com/.