Why are amplify.request.define and amplify.request separate methods?

[mandar katre]

Hi Experts,

Why are the amplify.request.define and amplify.request two separate methods in the API? If amplify.request.define and amplify.request are used in separate js files, in what scenario will this happen?

Can we make these 2 calls a single call using a simple wrapper?

[Scott González]

They're separate because as a person requesting data, you shouldn't care how the data is retrieved. If the request definition changes, you shouldn't have to update any of the actual requests. This is the entire purpose of the request module

If you were to merge amplify.request() and amplify.request.define() then you should just stop using amplify and use jQuery.ajax(), but that'd be a step backward.

You might want to watch this webinar from 2 years ago that shows the power of having them separated: http://amplifyjs.com/events/2011/03/webinar/ (about 19 minutes in).

[mandar katre]

Is it like once I define a request in one js file location with a unique resource Id string, the consumers can make any number of requests using the same definition. So, the request definition is something which can be reused?

In many examples on the internet, I came across request definition and request making it around 20 odd lines of code which can be possible with simple $.getJSON and $.post methods. Scott, I will appreciate if you provide some pointers. Thanks for your earlier post, it was helpful!

[Scott González]

On Tue, Feb 19, 2013 at 8:31 AM, mandar katre <katre....@gmail.com> wrote:

Is it like once I define a request in one js file location with a unique resource Id string, the consumers can make any number of requests using the same definition. So, the request definition is something which can be reused?

Yes, think of a request definition as a function. You can call it as many times as you want. When designing your app, it's often beneficial to think of yourself as a third party provider. When you're requesting data, assume that you know nothing about how what the data looks like, where it's stored, etc. All you know is that someone has promised that if you ask for data with a specific set of input (data), you will get a response in a specific format. amplify.request is a set of helpers around fulfilling that promise even when business or technical requirements result in changes to the actual data source. For example, if the required input format changes, you can use a data map to handle the change without updating any calls to the request. If the output changes, you can use a decoder to handle the change without updating any calls to the request. This goes on and on, you can even change from a local data source to a remote data source, JSON to XML, etc. and none of your calls to the request should ever have to change.

These abstractions also simplify integration with actual third party providers. Let's say you need to use some service that returns data in a format that's awkward to use for your app. Just use a decoder in the request definition, and you can design the service to work however you want.