CODEWITHSUNDEEP
phpooprestsymfonyguzzle
Jonathan McCaffrey
Jonathan McCaffrey

Reputation: 171

Symfony2 ReST Client Structure

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?

Upvotes: 17

Views: 1855

Answers (4)

user6376161
user6376161

Reputation:

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.

Upvotes: 2

Cobuz Alexandru
Cobuz Alexandru

Reputation: 322

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.

Upvotes: 1

Tom
Tom

Reputation: 2873

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.

Upvotes: 1

Luke Eller
Luke Eller

Reputation: 627

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.

Upvotes: 1

Related Questions