Symfony2 ReST Client Structure

| | August 4, 2015

I am trying to establish a best-practice pattern for ReST clients in Symfony 2, as this is a very common job for us at my company, where we have Symfony apps on the frontend edge talking to Java based backends over HTTP/ReST.

My thinking is this, these services fill the “Repository” role in DDD for the particular domain in question . Based on the conventions specified by Doctrine, these would go in Repository classes that return Entity objects.

I think that same convention can work here as well, ReST client implement a Repository class using a library like Guzzle or just straight Curl, doesn’t matter how, and then the code there does basic transformations from XML or JSON from and back to Entity objects for the upstream developer to manipulate. This is consistent with the patterns in other Symfony 2 use-cases and makes sense from a DDD standpoint.

Does anyone see a problem with this or a better way to do it?

2 Responses to “Symfony2 ReST Client Structure”

  1. This works if you correctly consider all the caching layers involved as well, to make sure that your Repository will not cache beyond the TTL of the REST object you retrieve (as set by etags or expire headers or whatever your REST server uses).

    Definitely Repository is the correct layer, though maybe in Symfony you want to go one level higher and consider it an entity manager, as it would allow you to abstract the operations on that level, such as persist, remove and flush.

  2. I like the approach you’ve outlined. You can think of your repositories as an anti-corruption layer, which isolates your ReST client code from your domain model.

Leave a Reply