Unify Schema/ResourceObject and Request/ResourceObject to improve developer experience
luispabon opened this issue · comments
Just implementing some stuff using this library 👍
One thing I've found rather confusing is having one ResourceObject entity for received resources and a different ResourceObject entity for when we need to create/update. Not only it was unexpected, it's cumbersome to use (class imports, converting one type into another) and very prone to error.
Also, the Request/ResourceObject entity is write-only, and the Schema/ResourceObject entity is read-only. This severely limits what can be done with the entities.
Use cases this separation gets in the way of include:
- Reading a resource from the API, modifying, then sending back for updating
- Unit tests on code that needs to evaluate ResourceObjects
- Referencing ResourceObject on classes that use both - always need to alias imports
These two should really be the same entity, I can't quite see any reason they should be different things entirely since they're virtually the same thing, and indeed on JSONAPI they're the same thing.
Hey there,
Thank you for your feedback! You are absolutely right that it's not so good that these classes share the same name. But I have to think about how to best solve the problem because there are some constraints:
Schema\ResourceObject
haslinks
andmeta
members, whileRequest\ResourceObject
doesn't- They even don't have the same relationships: relationships in request must only contain a
data
member, while relationships in responses can have much more information - I like to follow the Interface Segregation principle. Here is an example: when you process the response, you will never call the
setAttributes()
or thesetRelationships()
method, that's whySchema\ResourceObject
mustn't have them. This way the API becomes much easier to use: requests are writeable, responses are read-only.
So I'm not convinced at all that these classes should be merged together... But let's think a little bit:
- In order to solve the third problem, maybe they could just be renamed to something different.
- In order to handle your first problem a Factory Method
Request\ResourceObject::createFromResponse(Schema\ResourceObject $resourceObject)
could be added. - Another solution might be (which should solve all problems) to merge the two classes and create a
RequestResourceObjectInterface
and aResponseResourceObjectInterface
. I like it for the first sight, but I don't know if it really works.
I am curious about your opinion about what I've just written.
No, thank you for your hard work!
Another solution might be (which should solve all problems) to merge the two classes and create a RequestResourceObjectInterface and a ResponseResourceObjectInterface. I like it for the first sight, but I don't know if it really works.
I think that would work nicely. We've currently switched from our in-house JSONAPI client to yours and we used an approach similar to this. It helps streamlining developer experience when you don't need to be constantly converting back and forth.
Sorry for being so late! I'll try to come up with a solution, but the Summer is a bit hectic for me :P 😎
I started to experiment here with the last solution I proposed: #6
It's not ready yet, because I still have to work on the relationships (they also need two interfaces).