Add optional parameters to $get

[furinvader]

First of all, thank you very much for your hugely useful module.

Here I have added optional parameters to $get. So one could use resource.$get({ param1: 'foobar', param2: 42 }).then(...) to add additional URL parameters.

[jcassee]

Thanks for the contribution, Alex. Can you tell me a little bit about the use-case? In my mind, http://example.com/foo is simply a different resource from http://example.com/foo?bar=qux.

[furinvader]

Yes, sure. In the application where I'm going to use this change, the requested resource contains some filter dependent data. I figured it would be more concise not to basically have or use a new resource location for every possible filter combination.

Edit So it still has its own operations (links), although the data it has may change depending on its filters.

[jcassee]

Let's see if I understand you. You have a resource, say http://example.com/projects that represents a list of projects. You can now get http://example.com/projects?closed=true to get only a list of closed projects? In such cases I have used a templated relation, e.g. http://example.com/projects{?closed}. And indeed, every resolved template URI then become a separate resource.

Do you have a good example? (The example added to the README does not really make any sense: what does a pineapple have to do with John William's resource or representation?) I appreciate that you put effort into creating a clean, ready-to-merge pull request, but I need a bit more justification.

[furinvader]

Yes, your example puts it very well. I admit, that I am quite new to this API design as of yet and I didn't know about the templated relations.

Using your example, I would have to use the following code for it to work, right?

var projects = new ResourceContext().get('http://example.com/projects');
projects.closedHref = 'http://example.com/projects{?closed}';
var closed = projects.$propRel('closedHref', {closed: true});
closed.$get().then(...);

[furinvader]

If I can solve it that way (or kind of), I'll try. Then, the changes are not of much use.

Thank you very much for your time and your help!

[jcassee]

Your example looks good. I can totally see how the project list would have a link to the filter for that same list. The property should probably be named projects.filterHref, and the URI template could have more options, e.g. http://example.com/projects{?closed,archived,mine}.

Often, I find that I link to resources like a projects list from a generic resource that is commonly called the root resource, a resource that represents the different components or features that an API provides.

Good luck with the API design!