cujojs / rest Goto Github PK

How should I do an XHR/XDR that has withCredentials set to true? Basically I need it to send cookies along with the request (cookies were set server-side).

In plain JS I can do:

var xhr = new XMLHttpRequest();
xhr.withCredentials = true;

Here's what I tried with rest.js:

var myFirstInterceptor = interceptor({
    request: function handleRequest(request, config) {
        request.withCredentials = true;
        return request;
    }
});

var client = rest.chain(myFirstInterceptor);
client({path: '/foo'});

However, the request object here is not the "raw" XMLHTTPRequest, nor is the property copied onto the actual XHR object.

Can you help me out here? :-)

Configuring rest clients with wire.js is currently a pain, even with the current wire plugin. It needs to be much easier to wrap an client with more interceptors.

Current syntax:

client: {
    create: {
        module: 'rest/interceptor/hateoas',
        args: [
            {
                create: {
                    module: 'rest/interceptor/entity',
                    args: {
                        create: {
                            module: 'rest/interceptor/location',
                            args: { $ref: 'client!', mime: 'application/json', entity: false }
                        }
                    }
                }
            },
            { target: '' }
        ]
    }
}

A proposed syntax:

client: {
    rest: {
        parent: { $ref: 'baseClient' },
        interceptors: [
            { module: 'rest/interceptor/mime', config: { mime: 'application/json' } },
            { module: 'rest/interceptor/location' },
            { module: 'rest/interceptor/entity' },
            { module: 'rest/interceptor/hateoas', config: { target: '' } }
        ]
    }
}

the parent/baseClient is provided as an example of how to wrap another client. It should be removed form this example for functional equivalence with the current syntax.

Shortcuts to this syntax could also be introduced:

• use just the interceptors array if the default client should be the chain's parent
• use just the module id string if no config is needed
• use a shortcut namespace for interceptor modules ids (ie 'rest:entity' -> 'rest/interceptor/entity')

Current test coverage is from implementations of interceptor, it should be tested directly.

Cookies are commonly used to track clients across requests. Many APIs use cookies to track authentication after subsequent requests.

While browsers will automatically track cookies. Node does not provide such a facility.

Note: Programatic setting and reading cookies from HTTP headers is forbidden by the XHR spec. The cookie jar has no hope of ever working in browsers.

Refuses to work:

define({
    somePrefix: "whatever",
    client: {
        rest: {
            interceptors: [
                {
                    module: "rest/interceptor/pathPrefix",
                    config: {
                      prefix: { $ref: "somePrefix" }
                    }
                }
            ]
        }
    }
})

Reported by @monteslu on IRC. In rest.js now, it returns defaultClient as a wrapper around the actual client, but I don't think that defaultClient.chain is provided. That causes existing code that does rest(config).chain(...) to fail.

A workaround for existing code is to change it to rest(config).getDefaultClient().chain(...).

A possible fix might be to add a delegating chain to defaultClient just before the return defaultClient:

defaultClient.chain = function delegateChain() {
    return client.chain.apply(defaultClient, arguments);
};

when I use the timeout interceptor in the with the xhr client (XMLHttpRequest) it does not register the timeout property on the request.

So if a request takes very long and the promise returns, it still leaves the XMLHttpRequest open. In this case the browser will not have a timeout at all. In my case this caused IE8 to not send any requests anymore.

IMO the browser should be aware of the intended timeout anyways.

Their's an updated version of the HAL spec, we should support it. Current support is version 05.

http://tools.ietf.org/html/draft-kelly-json-hal-06

The config property is currently required to be an object.

Here's another issue of developer surprise, if not a bug: interceptor request handlers are executed in the opposite order that they are chained in. Is this the intended behavior? If it is, it is not obvious and should be documented somewhere.

The current client is for the next step in the chain. Consumers who need the parent client can get that client with skip().

When an error occurs (either thrown as an exception or an 'error' event in the case of Node), the client implementations should reject the pending promise with a response object rather than only the error object, allowing information such as the originating request to still be captured.

http://www.w3.org/TR/html5/embedded-content-0.html#mediaevents

wire docs say to use $plugins instead of plugins. Shouldnt it be updated in rest docs as well?

Currently, if an interceptor rejects the promise during the request phase, the value of the rejected is set as the 'error' property on the response object. It should also be possible to provide the cause for the error.

When loading a url from the local file system, the UrlBuilder will fail to parse the url.

The problem is that the urlRE field expects //, but file urls have 3.

The location interceptor will happily follow redirect loops, potentially forever. We should track the URLs that are being requested and error out if a cycle is detected. This behavior should be on by default, but disabled via configuration.

These browsers produce false positives when reporting back the test results.

The test suite finishes successful, but the summary text is not the expected value.

The documentation is not clear how/or whether we can do a chunked put/post of large file to rest API. The problem is I have a huge file ~110MB which I would like to post to a server. Any ideas? Or is there a way to add support for that?

Because the beget() function returns an object with the original object as the new object's prototype instead of attaching the properties directly to the new object, operations such as console.log and JSON.stringify do not work as expected on objects produced by beget(). More concretely, the config object that is passed around in an interceptor hides its properties from console.log and JSON.stringify.

I did a quick and dirty test using a simpler approach with a flat object that seems like it could work just as well, at least for the interceptor's config object:

function clone(obj, props) {
    var tmp = {};
    mixin(tmp, obj);
    if (props) {
        mixin(tmp, props);
    }
    return tmp;
}

I can see that this would be slightly less performant with a larger, more complex object, but the difference would be small. If it is not feasible to change the implementation, I think it would be worth at least mentioning the quirks of beget() and therefore the interceptor config object, because its surprising and unexpected behavior makes writing custom interceptors more challenging.

I'll mention, since it could be useful to others, that I am using the following in my custom interceptor for debugging purposes. Note that this negates any performance advantages of using prototypal inheritance inside beget():

init: function(config){
    for (var k in config) config[k] = config[k];
    ...
}

Hello,

it would be really great if one could pass custom reviver / replacer to the json and hal converters. At the moment it is not possible without duplicating most of the code and register it as custom converters.

Julien

http://tools.ietf.org/html/rfc6570

This is useful for interceptor that need to initiative a subsequent request. Currently the best they can do is to reuse themselves, or ask the user to explicitly override the client. Often it would be better to reuse the full client interceptor chain.

http://tools.ietf.org/html/draft-kelly-json-hal-05

IE 8 and 9 do not implicitly support cross origin requests via CORS. The XDomainRequest object is similar to the XMLHttpRequest object but can make cross origin requests.

We should provide an interceptor that will automatically switch to XDomainRequest when necessary.

Currently once an error state is encountered, the response from an interceptor will also be in error. It should be possible for an interceptor to recover from an error.

Currently, the boundaries of the object graph managed by the hateoas interceptor return a promise for the related resource each time the property is accessed. This is counter intuitive to normal property access which would return the same object.

http://twitter.github.com/bower/

Hi,

Is it possible to do an synchronous reques?

I didn't find an interceptor or setting anywhere.

The XHR client has async "true" hard coded.

Cheers,
Jose

If a string is provided as the request object, it should normalize to { path: ..value.. }

See http://blog.springsource.org/2013/08/21/spring-security-3-2-0-rc1-highlights-csrf-protection/

Cancel the request if a response is not received within the specified time

Hi,

Do you know if REST is supposed to work with IE8 and if its been tested with IE8? Currently it works in IE9+ but not 8.

Jose

It should be possible to use RestStore without pulling in 'all' of dojo. RestStore currently pulls in dojo/store/util/QueryResults, this is a convenience util and isn't strictly necessary.

Consider removing QueryResult from the RestStore, or introduce a 'SimpleRestStore' that contains the core RestStore functionality without the dojo dependency.

I'm working on a dynamic javascript library inside Spring Data REST, the project that automatically exports REST endpoints. The idea is to provide a JS library instead of requiring the dev to write their own RESTful handler. It would be available at /jsclient/{library}, where currently I've coded /jsclient/jquery. I would also like to code /jsclient/restjs. I'm interested in feedback on how to best code a restjs version of this.

You can see my work on a branch at https://github.com/gregturn/spring-data-rest/commits/dynamic-javascript. The latest commit with my work is at gregturn/spring-data-rest@4e5ecdb. If you scroll past all the log statements, you'll find some templated javascript that is used to generate jquery-specific code like this:

var sdr = {
    personRepository: {
        findAll: function(){
            return $.get('/people');
        },
        create: function(obj){
            return $.ajax({
                type: 'POST',
                url: '/people',
                data: JSON.stringify(obj),
                contentType: 'application/json'
            });
        },
        replace: function(id, obj){
            return $.ajax({
                type: 'PUT',
                url: '/people/' + id,
                data: JSON.stringify(obj),
                contentType: 'application/json'
            });
        },
        update: function(id, obj){
            return $.ajax({
                type: 'PATCH',
                url: '/people/' + id,
                data: JSON.stringify(obj),
                contentType: 'application/json'
            });
        },
        "delete": function(id){
            return $.ajax({
                type: 'DELETE',
                url: '/people/' + id
            });
        },
        findByLastName: function(name){
            return $.get('/people/search/findByLastName', { name: name });
        }
    }
};

What would be a good/similar solution using restjs?

see spring-projects/spring-data-rest#13

The "rest/client/jsonp" module is throwing a generic "Object doesn't support this action" error in IE8 when making a JSONP request.

@unscriptable narrowed the problem down to something in here https://github.com/cujojs/rest/blob/master/client/jsonp.js#L106-L108. If i remove line 107 script.onerror(e); i no longer saw the error.

One thing to note is that the request is successfully returning from the server and rest is not failing the request, just an error is being thrown.

http://tools.ietf.org/html/rfc5988

Currently only the ClientResponse is provided. For XHR, the request and response are wrapped into the same object.

The mime registry is currently global, it's possible that different client will want different interpretations of the same mime type. Allowing a custom registry while defaulting to the global registry address this issue.

http://tools.ietf.org/html/draft-kelly-json-hal-05

Implement a client side HTTP 1.1 compliant cache as an interceptor. Browsers automatically provide a cache, but Node does not.

The low level cache impl should be a plugable strategy.

Hey Scott,

I don't know how you want to handle this, but I just encountered a fun one: the XHR shim in Intel's XDK (Cordova-based mobile app environment) duplicates all response headers. (Actually, they're not quite duplicates: one is Proper-Case, the other is lower-case.)

This is obviously a bug in their shim. However, I was wondering if this could happen in non-buggy situations? If not, just close this. :)

-- John

Line of interest: https://github.com/cujojs/rest/blob/master/interceptor/mime.js#L79

It's currently possible for a client to make a request even if the response has already been cancelled. This behavior is currently exhibited with the timeout and retry interceptors.