Hi,
I''m adding an API to a Rails app where clients will be able to create
records on the DB. I''ve been reading around but didn''t find a
good set
of characteristics that the API should have. These are the things I have
in mind.
- Access controlled by token and over ssl
- Versioned so I can improve it safely
- REST based (though I''m not obsessed with it, the scope of the API is
quite reduced and affects just 2 resources in exactly the same way)
- I will limit the content length to avoid too big request and force
clients to breakdown the requests if needed
Using the API the users will be able to create, modify or delete two
types of very basic resources. Updates and deletes are not expected to
be very frequent actions anyway.
For example for a create action I''ll take JSON arrays included in the
request body as input from the clients:
{
"entries": [
{ "ind_id":11 , "elem_id":22, "value":33.44,
"scope":"22-2012" },
{ "ind_id":13 , "elem_id":null, "value":35.45,
"scope":"22-2012" },
{ "ind_id":14 , "elem_id":24, "value":63.44,
"scope":"22-2012" },
{ "ind_id":15 , "elem_id":25, "value":73.74,
"scope":"22-2012" }
]
}
My questions and worries:
- Initially I thought of creating an array of hashes and pass that to
the create method. But a simple test showed me that if one fails the
rest go through and I don''t get any straight indication of which one
failed. So I think I should get all the items in one post and planned
but then create the records one by one, that way I can collect data if
any fails and report back to the clients. Is that a bad idea?
- I guess there should be a background job taking care of inserting the
records to the DB, I''m not sure how would I communicate back with the
client?
Any good hints regarding this topic?
--
Posted via http://www.ruby-forum.com/.
--
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
> > Initially I thought of creating an array of hashes and pass that to > the create method. But a simple test showed me that if one fails the > rest go through and I don''t get any straight indication of which one > failed. So I think I should get all the items in one post and planned > but then create the records one by one, that way I can collect data if > any fails and report back to the clients. Is that a bad idea?Can''t think of a reason why it could be a bad idea... I guess there should be a background job taking care of inserting the> records to the DB, I''m not sure how would I communicate back with the > client?The method of status communication would depend on the type of your client. Any feasible publisher subscriber pattern implementation should be your best bet. Polling should be the last option. If its a web client, you can check out websockets for resource efficient real-time communication. On Monday, November 26, 2012 1:25:43 PM UTC+5:30, Ruby-Forum.com User wrote:> > Hi, > > I''m adding an API to a Rails app where clients will be able to create > records on the DB. I''ve been reading around but didn''t find a good set > of characteristics that the API should have. These are the things I have > in mind. > > - Access controlled by token and over ssl > - Versioned so I can improve it safely > - REST based (though I''m not obsessed with it, the scope of the API is > quite reduced and affects just 2 resources in exactly the same way) > - I will limit the content length to avoid too big request and force > clients to breakdown the requests if needed > > Using the API the users will be able to create, modify or delete two > types of very basic resources. Updates and deletes are not expected to > be very frequent actions anyway. > > For example for a create action I''ll take JSON arrays included in the > request body as input from the clients: > > { > "entries": [ > { "ind_id":11 , "elem_id":22, "value":33.44, "scope":"22-2012" }, > { "ind_id":13 , "elem_id":null, "value":35.45, "scope":"22-2012" }, > { "ind_id":14 , "elem_id":24, "value":63.44, "scope":"22-2012" }, > { "ind_id":15 , "elem_id":25, "value":73.74, "scope":"22-2012" } > ] > } > > My questions and worries: > > - Initially I thought of creating an array of hashes and pass that to > the create method. But a simple test showed me that if one fails the > rest go through and I don''t get any straight indication of which one > failed. So I think I should get all the items in one post and planned > but then create the records one by one, that way I can collect data if > any fails and report back to the clients. Is that a bad idea? > > - I guess there should be a background job taking care of inserting the > records to the DB, I''m not sure how would I communicate back with the > client? > > > Any good hints regarding this topic? > > -- > Posted via http://www.ruby-forum.com/. >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-talk/-/tOvcPhK8SpsJ. For more options, visit https://groups.google.com/groups/opt_out.
Vibhor wrote in post #1086437:>> >> Initially I thought of creating an array of hashes and pass that to >> the create method. > > > Can''t think of a reason why it could be a bad idea...Performance wise. I imagine it would be faster to pass the array of hashes to the create method. But then I''d need to build some mechanism to verify the success and would probably be even worse than creating one by one.> > I guess there should be a background job taking care of inserting the >> records to the DB, I''m not sure how would I communicate back with the >> client? > > > The method of status communication would depend on the type of your > client. > Any feasible publisher subscriber pattern implementation should be your > best bet. Polling should be the last option. > If its a web client, you can check out websockets for resource efficient > real-time communication.Each company using the product will implement their own client to use the API. JSON over http so I guess that makes it a web client. I should find out more about websockets thanks for the pointer. Thanks Vibhor. -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit https://groups.google.com/groups/opt_out.