Алексей Веркеенко "Symfony2 & REST API"
3 likes1,995 views
This document discusses Symfony2 and REST APIs. It provides an overview of REST including its history and core concepts like requests, responses, and URLs to identify resources. It also discusses best practices for building REST APIs with Symfony2, including using a wrapper class, error handling guidelines, and documentation/monitoring goals.
Ad
More Related Content
What's hot (20)
Viewers also liked (20)
Ad
Similar to Алексей Веркеенко "Symfony2 & REST API" (20)
Ad
More from Fwdays (20)
![[QUICK TALK] "Why Some Teams Grow Better Under Pressure", Oleksandr Marchenko...](https://cdn.slidesharecdn.com/ss_thumbnails/softskillsfwdays25-250317080651-1a2cccb1-thumbnail.jpg?width=560&fit=bounds)
![[QUICK TALK] "How to study to acquire a skill, not a certificate?", Uliana Du...](https://cdn.slidesharecdn.com/ss_thumbnails/ulianadutchakhowtostudytoacquireaskillnotacertificate-250317080232-421f309c-thumbnail.jpg?width=560&fit=bounds)
![[QUICK TALK] "Coaching 101: How to Identify and Develop Your Leadership Quali...](https://cdn.slidesharecdn.com/ss_thumbnails/softskillsfwdays25ilonalesko-250317075721-cb56ed6c-thumbnail.jpg?width=560&fit=bounds)
Recently uploaded (20)
Алексей Веркеенко "Symfony2 & REST API"
- 1. Symfony2 & REST API Alexey Verkeenko Grossum [email protected]
- 2. WHAT IS REST? • REST (Representational State Transfer) is the software architectural style of the World Wide Web. • REST gives a coordinated set of constraints to the design of components in a distributed hypermedia system that can lead to a higher-performing and more maintainable architecture.
- 3. A BIT OF REST HISTORY • This technology became popular, when it was described in detail and presented by Roy Fielding in his doctoral dissertation called “Architectural Styles and the Design of Network-based Software Architectures” in 2000.
- 4. REST RULES • The general rule stands that each unit of information is identified by URL – which means, in turn, that URL in essence is the primary key for the data unit. • For example, third book on the bookshelf would have a view of /book/3, and 35th page of that book would be found here: /book/3/page/35.
- 5. FULL LIST OF REQUEST TYPES • CONNECT • DELETE • GET • HEAD • OPTIONS • PATCH • POST • PUT • TRACE
- 6. RESPONSE CODES • There are 38 response codes and you can see the list on the right:
- 7. API TRANSACTION EXAMPLE • One transaction for this API would consist from following (minimum): • Request method, for example, GET • Request path, for example, /object/list • Request body, for example, form • Response code, for example, 200 OK • Response body, for example data in JSON format
- 8. REST EXCLUSIONS • You cannot call a service a REST one, if: • It has single point of entry • All requests are processed by POST method • Response metadata is located in the body of the response and not in its header • URL-addresses contain method names
- 9. REST ADVANTAGES • The advantages of using REST in our projects: • All our resources have unique identifiers (URL), which gives us an opportunity to logically formulate our requests and structure URLs available for requests • Universality. You can use the same server response data to return back to XML or JSON for software processing or to wrap in a beautiful design for people to see. • REST is a service that implements actual service- oriented architecture (SOA), an architectural pattern in computer software design in which application components provide services to other components via a communications protocol, typically over a network.
- 10. ERRORS GUIDELINES • Basic error informing guidelines: • Use expected format • Do not neglect available response types • Show coherent messages
- 11. USAGE PROBLEMS • Absence of mutual agreement and standardization • Partial support of response headers • Different clients’ behavior for the same response code • Complex process of searching for errors during development
- 12. REQUEST OPTIONS • Safe request – a request that does not change the application’s condition. • Idempotent request – a request, the multiple execution of which equals to the single execution effect.
- 13. CORRELATION TABLE • Table of HTTP method correlation for safe and idempotent requests: HTTP-method Safe Idempotent GET Yes Yes HEAD Yes Yes OPTIONS Yes Yes PUT No Yes DELETE No Yes POST No No
- 14. MONITORING GOALS • In order to choose correct instruments and concentrate your attention on really important issues, begin from identifying main needs you want to satisfy with monitoring.
- 15. TWO QUESTIONS TO ASK • Ask yourself these two questions: • What do I want to find out? • What am I planning to do based on this information?
- 16. WRAPPER CLASS • Do not call API directly from your code. Instead, implement a wrapper class for it. • This allows you to: • Cache results if the response speed is not high or there is a big data exchange • In case you need to incorporate changes, you only have to do it in one place • Convenient implementation because you only deal with one class • Mock-object’s easy realization to change our wrapper class during the work on testing
- 17. CREATION AND DOCUMENTATION • You can find information here: • https://restunited.com/ • https://apimatic.io/ • http://swagger.io/
- 18. • Upload the bundle and its dependencies with the help of composer: • Connect it to the application core: IN THE BEGINNING…
- 20. POST ENTITY
- 21. FORM & CONTROLLER CREATION
- 22. FORM TYPE
- 23. POST CREATION
- 24. PUT ACTION
- 25. PATCH ACTION
- 26. DELETE ACTION
- 27. THANK YOU! GOT QUESTIONS? Alexey Verkeenko [email protected] Grossum