learn-co-curriculum/python-p4-building-post-patch-delete-api

python-p4-building-post-patch-delete-api's Issues

Implication Unclear

Canvas Link

https://learning.flatironschool.com/courses/6182/assignments/208453?module_item_id=480486

Concern

What exactly are we trying to communicate with this section?

"We all know from experience that we can delete resources on the internet: emails, Instagram posts with unmade beds in the background, etc. Many of these can be performed from the browser, but we don't support them from our API. Why is that?

Browsers are actually very flexible on this front- it's HTML that isn't. The W3C specifications for HTML say that it should only support GET and POST. This means that any requests sent to the API through the browser with unsupported methods will have these methods cast to GET...which will then be used to update and delete resources. (We don't want that!)"

What do we mean that we don't support them from our API? Also, what's the solution to sending non-POST or GET requests? Is it just specifying the request method in the body? Or is it some other technique?

As of now, it's very unclear what the implications of this information are. It's not clear why this info is relevant to what we're currently doing, nor is it clear how we should resolve the challenges discussed. I think we could either elucidate what we mean more clearly or simply truncate this section.

Additional Context

No response

Suggested Changes

No response

jsonify imported but not used

Canvas Link

https://learning.flatironschool.com/courses/6259/assignments/233443?module_item_id=547399

Concern

If you look at code snippets or the solution code, jsonify was never used even though it was imported at the top.

Additional Context

No response

Suggested Changes

No response

Initial setup incorrect paths

Canvas Link

https://learning.flatironschool.com/courses/6182/assignments/208453?module_item_id=480486

Concern

We are referencing an app folder, not the server folder, we should update this

Additional Context

No response

Suggested Changes

No response

Typo in code example.

Canvas Link

https://learning.flatironschool.com/courses/6267/assignments/236244?module_item_id=554230

Concern

Section: Handling PATCH Requests, second code example.

The app route writes the route as '/reviews/<int:id', which is missing its closing angle bracket.

Additional Context

No response

Suggested Changes

'/reviews/int:id'

Reason for using .filter_by?

Canvas Link

https://learning.flatironschool.com/courses/6182/assignments/208453?module_item_id=480486

Concern

In previous lessons / examples, we've used basic .filter querying to select a specific resource. However, in this lesson we're choosing to use .filter_by, which has slightly different notation. Any particular reason we're choosing to use this here instead of .filter? If so, it might be helpful to make a note of it, as it's probably something students will pick up on and have questions about.

Additional Context

No response

Suggested Changes

No response

Unnecessary Line of Code under @app.route('/reviews/<int:id>)

Canvas Link

https://learning.flatironschool.com/courses/6275/assignments/237679?module_item_id=558421

Concern

Under the PATCH method for this code-along, the review variable is duplicated. Not sure if it really matters but this can be deleted since it's already called at the beginning of def review_by_id(id):

@app.route('/reviews/<int:id>', methods=['GET', 'PATCH', 'DELETE'])
def review_by_id(id):
    review = Review.query.filter(Review.id == id).first() <------------LINE ALREADY IN METHOD'S GLOBAL SCOPE

   <-------OTHER CODE FOR GET AND DELETE--------->

        elif request.method == 'PATCH':
            review = Review.query.filter(Review.id == id).first()` #<--THIS LINE IS NOT NEEDED

Additional Context

No response

Suggested Changes

No response

Will all POST and PATCH requests be accessible with .form?

Canvas Link

https://learning.flatironschool.com/courses/6182/assignments/208453?module_item_id=480486

Concern

Text:

The request context has access to form data, among many other things. While we haven't created a form here, makeshift forms can still be attached to requests and their attributes can be parsed to create new records.

Will we always write request.form.get("attribute") when handling post or patch requests in Flask? This description doesn't really make it clear whether or not this is something we'll always be doing, nor does it describe how this "makeshift form" was attached to the request. Also, what do we mean that we "haven't created a form here"? Is that referring to frontend code or our python code?

I think adding some clarification here could be quite helpful for students. As of now, this description doesn't really explain why we're doing what we're doing in our code, and almost makes it more confusing.

Additional Context

No response

Suggested Changes

No response