Symfony2 ReST Client Structure

Question

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?

score 2 · Answer 1 · edited May 26 '16 at 12:02

2

Following is the best article to deal with REST API development in symfony2:
http://welcometothebundle.com/symfony2-rest-api-the-best-2013-way/

The FOSRestBundle and NelmioApiDocBundle is good choice for fast rest api development. You can visit official documentation to know how to install, configure and use it.

edited May 26 '16 at 12:02

d.raev

9,216
8
58
79

answered May 26 '16 at 10:35

1

Question is about REST client code structure, not API – Nikolay Krasnov Jan 17 '18 at 21:32

score 1 · Answer 2 · answered Dec 07 '12 at 20:14

1

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.

answered Dec 07 '12 at 20:14

Luke Eller

627
1
7
23

score 1 · Answer 3 · answered Jun 23 '15 at 10:08

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.

score 1 · Answer 4 · answered Apr 13 '16 at 11:34

I think you are misusing the repositories in Symfony if you plan to use them like that. It would be better to have setters and getters inside your repository and the processing with guzzle/curl to do in a service.

Controller / Command -> Service methods -> Repository

Then, depending on your needs, you can write a Command/Controller to expose the methods in the service based on your needs.

Symfony2 ReST Client Structure

4 Answers4