4 ms·

REST APIs with Symfony2: The Right Way

28 points by couac 14y ago

happywolf 14y ago
I tried to read the article twice, but still fail to see what is the 'right way' the author tries to explain. Anybody care to enlighten me on that?
- couac 14y ago
  I'm sorry if you missed the big picture. The aim of this article was to show how to quickly build decent APIs using the Symfony2 framework. As far as I know, there was nothing documented yet. "The right way" mainly means using the right tools and following best practices.
- ihsw 14y ago
  It appears FOSRestBundle seems to be the main point of the article, and adding support for the LINK and UNLINK HTTP verbs is also interesting. There's also the allusion to custom content-types and versioning schemes and a small bit about using the SF2 web client and crawler for (unit) testing.
programminggeek 14y ago
The article starts with this...."Designing a REST API is not easy. No, really! If you want to design an API the right way, you have to think a lot about everything, and either to be pragmatic or to be an API terrorist. It’s not just about GET, POST, PUT, and DELETE. In real life, you have relations between resources, the need to move a resource somewhere else (think about a tree), or you may want to set a specific value to a resource." It seems like developers are making this too hard. At some point you're just sending data over http, so why does this have to be dogmatic and needlessly complicated just to match some mystical HATEOS spec that doesn't need to exist to get the job done?
- caseysoftware 14y ago
  There's a balance in there between "getting it done" and "getting it right(tm)" and then there's the definition of "right" ;) "Getting it done" is great for something entirely internal where you have control over all the end points. You have insight and understanding that you don't have to express to anyone outside your organization. Further, if you get it "wrong" deploying updates and new versions is easy (by comparison). "Getting it right" is key if you want something to go beyond your immediate circles. It should be as self-descriptive as possible to promote clarity. It should be consistent as possible to improve documentation/understanding. And the risk if you get it "wrong" is much higher because there are end points/API consumers that are not under your control, therefore you have to support a variety of versions for potentially long periods of time. (Biased as I regularly speak on API design and work for Twilio. We have a 2008 and 2010 version of the API. While we still fully support the 2008 version, the 2010 version has a great deal more functionality.)
newgrad 14y ago
Hmm, I don't understand why the author said that if we use OAuth, having CSRF protection does not make sense. Does anybody know why?

28 points by couac 14y ago

I tried to read the article twice, but still fail to see what is the 'right way' the author tries to explain. Anybody care to enlighten me on that?

couac 14y ago
I'm sorry if you missed the big picture. The aim of this article was to show how to quickly build decent APIs using the Symfony2 framework. As far as I know, there was nothing documented yet. "The right way" mainly means using the right tools and following best practices.
ihsw 14y ago
It appears FOSRestBundle seems to be the main point of the article, and adding support for the LINK and UNLINK HTTP verbs is also interesting. There's also the allusion to custom content-types and versioning schemes and a small bit about using the SF2 web client and crawler for (unit) testing.

programminggeek 14y ago

The article starts with this...."Designing a REST API is not easy. No, really! If you want to design an API the right way, you have to think a lot about everything, and either to be pragmatic or to be an API terrorist. It’s not just about GET, POST, PUT, and DELETE. In real life, you have relations between resources, the need to move a resource somewhere else (think about a tree), or you may want to set a specific value to a resource." It seems like developers are making this too hard. At some point you're just sending data over http, so why does this have to be dogmatic and needlessly complicated just to match some mystical HATEOS spec that doesn't need to exist to get the job done?

caseysoftware 14y ago
There's a balance in there between "getting it done" and "getting it right(tm)" and then there's the definition of "right" ;) "Getting it done" is great for something entirely internal where you have control over all the end points. You have insight and understanding that you don't have to express to anyone outside your organization. Further, if you get it "wrong" deploying updates and new versions is easy (by comparison). "Getting it right" is key if you want something to go beyond your immediate circles. It should be as self-descriptive as possible to promote clarity. It should be consistent as possible to improve documentation/understanding. And the risk if you get it "wrong" is much higher because there are end points/API consumers that are not under your control, therefore you have to support a variety of versions for potentially long periods of time. (Biased as I regularly speak on API design and work for Twilio. We have a 2008 and 2010 version of the API. While we still fully support the 2008 version, the 2010 version has a great deal more functionality.)

newgrad 14y ago

Hmm, I don't understand why the author said that if we use OAuth, having CSRF protection does not make sense. Does anybody know why?