On 11 June 2012 09:14, Ahmy Yulrizka <ahmy135@gmail.com> wrote:
> Dear All,
>
> I'm trying to build a ruby library to communicate with a REST API. I'm
> thinking to make it as an abstraction so it can be modular.
> for example
>
> the API is structure as RESTful web service which is Rails like
>
> /devices -> list all device
> /devices/12 -> show specific device
> /documents
> /documents/14
>
> etc.
>
> The problem that I'm facing it structuring the library with module and
> class. I wanted to make something like
>
> client = MyLibrary.new user: 'user', password: 'password'
>
> array_of_devices = client.devices.all -> GET /device
> devies = client.device.create -> POST /device
> device = client.device.get(1) -> GET /device/1
>
> document = client.document.new(device)
> document.save
>
> and maybe in the future
> document.device -> will return the device where the document belongs to
>
> etc.
>
> first of all is storing the config (user and password) because all of the
> api needed this. My question is how to I structure it.
I am not sure I fully understand the problem as the answer seems
obvious, but if I do understand then the config would be stored as
attributes of the MyLibrary object, so would be available as
client.user or self.user, for example, when inside the class.
>
> client.devices will return module or class ?
> and how to share config variable with the other class or module within the
> library.
Presumably client.device would be Device object, whatever that is,
though again I am not sure I understand the question fully.
Have you looked at ActiveResource? I have not used it myself but I
think it may already do what you are trying to achieve.
Colin
--
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@googlegroups.com.
To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
No comments:
Post a Comment