Closed j closed 11 years ago
I think that it'd be best if this was named ignore_failure
, and that all kind of exceptions would be catched inside the LinkFactory, that would also cover the case where route parameters are incorrect (a null value ?).
Also, the RelationsBuilder, RelationsManager classes should be updated.
Yeah, renaming it makes sense in it's current implementation, but i feel that it is a hacky way of achieving this...
Basically, we need to be able to achieve the following (which is pretty common, IMO)...
class User
{
/** @var \MongoId **/
public $id;
/** @var User */
public $bestFriend;
}
and I'd want this to look like:
{
"user": {
"id": "abcd1234",
"links": {
"best_friend": "/users/defg5678",
"self": "/users/abcd1234"
}
}
}
... and when we have a loner hipster troll kid who has no friends:
{
"user": {
"id": "abcd1234",
"links": {
"self": "/users/abcd1234"
}
}
}
Right now, not having this ability is a show stopper... And we have to finish this API by january! :(
100 points for saying "loner hipster troll kid"... lol
How about introducing a new relation type class
which you can reference another configured serialized or HateOAS class...
i.e.)
/**
* @Rest\Relation("best_friend", class="FSC\HateoasBundle\Tests\Fixtures\User")
*/
... or ... even sexier (make this default behavior) ...
/**
* @Rest\Relation("best_friend", "FSC\HateoasBundle\Tests\Fixtures\User")
*/
@baldurrensch :P
:trollface:
Actually, I'm thinking in terms of python right now with having the ability to make a model an actual resource and auto generating routes for it. So I don't think the class type would work ;( Anyway, hopefully I can figure something out so we can move forward over here.
What's the status of this PR / feature ?
This is quite a common need and the require
attribute sounds good to me. Basically the bundle configure a Representation and its requirements.
Yet, since I work with a lot a third-party API, when consuming an API, I prefer verbosity (i.e. the key name with an default/empty value) because I had much surprises with some outdated documentation (or no documentation at all) and some optional fields... But it's a "cheap" choice for consistency (wire overheat, weird 'null' logic, ...)
@j @ludofleury Does #42 solve your use cases ?
Closing as #42 is going to be merged
This simply omits the link completely an Symfony\Component\Form\Exception\UnexpectedTypeException is thrown.
In other words, if I have the following config:
if bestFriend.id does not exist in the User object (meaning null in most cases), then we'd omit the best_friend link completely.
I feel this is less of a hack then doing this manually or creating subscribers for every single object that may need this... Maybe even eventually hooking into the objects validation and seeing what fields are required and taking that value from there by default (since that's what most people would want anyway)
This pertains to #21