SymfonyCasts stands united with the people of Ukraine
// composer.json
{
"require": {
"silex/silex": "~1.0", // v1.3.2
"symfony/twig-bridge": "~2.1", // v2.7.3
"symfony/security": "~2.4", // v2.7.3
"doctrine/dbal": "^2.5.4", // v2.5.4
"monolog/monolog": "~1.7.0", // 1.7.0
"symfony/validator": "~2.4", // v2.7.3
"symfony/expression-language": "~2.4", // v2.7.3
"jms/serializer": "~0.16", // 0.16.0
"willdurand/hateoas": "~2.3" // v2.3.0
},
"require-dev": {
"behat/mink": "~1.5", // v1.5.0
"behat/mink-goutte-driver": "~1.0.9", // v1.0.9
"behat/mink-selenium2-driver": "~1.1.1", // v1.1.1
"behat/behat": "~2.5", // v2.5.5
"behat/mink-extension": "~1.2.0", // v1.2.0
"phpunit/phpunit": "~5.7.0", // 5.7.27
"guzzle/guzzle": "~3.7" // v3.9.3
}
}Making RESTful APIs is hard, really hard. There are a lot of concepts to know - resources, representations, HTTP methods, status codes, etc.
Course 1 got us really comfortable with all the terminology. So in episode 2, we're attacking the hard stuff:
This stuff is not easy. But if you make it through, you'll be armed to attack whatever API need you have.
Your Guides
No timeline currently, but we do have the coding done, which means we're quite far along. Best case-scenario 1 month, but we'll try to release things piece-by-piece. You can press the "Notify Me" button on top and we'll email you when anything comes out :).
Thanks!
Hi Guys,
In this post:
http://knpuniversity.com/bl...
you talked about possibly creating 2 tutorials: one for generic PHP and one for Symfony, using FOSRestBundle. I've already been digging in the first screencast, Rest, but I see that this second episode is still not about Symfony. Are still planning to release this Symfony screencast?
Cheers! Thanks a lot for your work! :)
Hi Pablo!
It will be a bit off in the future, but yes, I think it's still something I'd like to do! In these episodes, we'll cover all the real work and knowledge you need for the REST API. A potential future Symfony version would just show you the specific implementation details inside of Symfony. So it wouldn't have all of the meat that these episodes have, but I think it would still be very useful. If you're on our mailing list, we'll definitely let you know.
Cheers and you're very welcome :)
You guys - are creating the best tutorials ever! I mean seriously! If this was A TV channel I would start watching TV again and never missed an episode. Hey, let's make a deal - if I find any newblood I will send them immediately here and on your part -> you will keep up good work! :)
Yo Milan V.! You just made our day :). Comment shared in our internal Slack for everyone. Thanks for super nice comment :D :D
Just finished Ep1, can't wait for more programmer battle awesomeness! any updates on when Ep2 is out?
Ha, awesome! We're working on ep2 (will be *great*), but it's still at least a few weeks out. Make sure you're subscribed for notifications at the top of this page and we'll shoot you an email.
Thanks!
Hola - the Course 3 ( http://knpuniversity.com/sc... ) does not exist, can help on how do I can learn the documentation part ?
Hey Andreas,
Womp womp womp... unfortunately, we don't have any courses to cover API docs, but here's a few most popular bundles on GitHub which has good docs will help you with it:
- FriendsOfPHP/Sami
- nelmio/NelmioApiDocBundle
- ApiGen/ApiGen
I hope this helps.
Cheers!
Hi Sergio!
If you own this chapter (or have a subscription), you should see the download link in the upper right on any video page (not this page, but any of the individual chapter pages). If you don't have a subscription, but want to get the source files, you can grab the starting point of the project here: https://github.com/knpunive.... It's on our list to make this an easier download link for non-subscribers :).
Cheers!
I need help how to setup an endpoint for this scenario...
I have a resource called Products and the following endpoint returns the list of products: /products.json
Suppose I want to return a representation which contains only a key/pair of the id and name of the product.
e.g:
[
1: 'CD',
2: 'Monitor',
3: 'Keyboard'
]
Should passing a parameter be the correct solution for this?
/product.json?type=list
Hey Jake!
Ah, philosophical REST questions, they're mostly touch because either nobody has an answer, or the answer makes your life unnecessarily difficult :).
In this case, this is clearly a "Product collection" representation, just not the normal JSON structure that you usually use. So, philosophically, I think it *is* correct to use the same `/product.json` URL that you use for the normal return. Now, *usually* if an endpoint returns different formats, you're supposed to read the Accept header sent by the client. Normally, the use-case is that your API endpoint returns JSON or XML, and the Accept header tells the server which one the client wants. But here, technically, *this* JSON representation and the normal JSON representation are just different "formats" of the same resource. So one "technically" right answer might be that you give this type of response some new Content-Type (e.g. application/vnd.simple-list+json) and read the Accept header to see if they want this format over the normal one.
But in practice, that looks *crazy* to me. Go with your query parameter - it still follows most of these rules, but is also pretty practical. Try to minimize custom things like this, but at the same time, if you're building your API for your *own* consumption (i.e. you're not creating a public API), you can bend the rules a bit more.
Great question - I love (and hate) this stuff! :P
Well, just finished my first viewing! Sweet stuff, time to rewatch it and build something now! Congrats guys!
I'm really looking forward to see this course coming up! Can't wait for it ;)