We Keep Coding

SAS: proc http working - request.get in Python does not - why?

have tried looking into other similar question and search the web, but I cannot seem to find the answer, so hope some clever people here can help or guide me.
I have a proc http request in SAS which runs fine on my local machine, no problems:
filename lst temp;
proc http
url = "http://xxx/api/job/"
method = "get"
out = lst;
run;
libname lst json fileref=lst automap=create;
Trying to do the same in Python gives me error code 401.
import requests
response = requests.get("http://xxx/api/job/")
print(response)
print(response.status_code)
This is an API from a system running internally in our organization. One needs to log on the first time when accessing through a web browser, but then it works.
I have tried all the different auth= etc. I could find in the documentation giving my user and password. But, nothing seems to work.
Some how, SAS proc http must be working since my profile/user is somehow verified, but via Python it is not - or at least that is what I am thinking.
Any suggestions?

FastAPI: Cannot get error handling to work as expected

I am just learning FastAPI (and loving it), so it is quite likely I am doing something wrong. But here is my problem:
In the code snippet below, I am creating a new user, if there is no user already.
The code works fine, but it is the error handling that I am having trouble with. The errors are properly being pushed forward to FastAPI's internal docs or to an API client like Postman, but not back to the actual client that I am using or the command line.
#app.post("/users/", response_model=schemas.User)
def create_user(user: schemas.UserCreate, db: Session = Depends(get_db)):
db_user = crud.get_user_by_username(db, username=user.username)
if db_user:
raise HTTPException(
status_code=400, detail=f"Username '{user.username}' already registered"
)
return crud.create_user(db=db, user=user)
If I use the auto-generated FastAPI docs (or Postman) and monitor the response in that way, I get the error I am expecting:
But when I look at what I am receiving at the client end (Vue) or what the uvicorn server is logging, it does not contain that information:
As you can see, it just says Bad Request instead of responding with the JSON dict of {"detail": "Username 'miketest' already registered"}
What am I doing wrong? What can I do to make sure that the full HTTPException information is being returned? I am pretty sure the problem is on the FastAPI end, because the client is receiving exactly what the server is outputting as well.

I figured out the problem, and it was not a FastAPI issue, per se, but it was on how it passes information back to the front end.
I thought I should keep this question in case someone has the same issue.
Solution:
try {
await api().post('register',JSON.stringify(data);
} catch (err) {
error = err.response.data.detail;
}
That is to say, the error sent from FastAPI is an object that has a response, and in it a data, and in that a detail.
The response from Postman or anything similar just gives an object with detail. I did not see that there was a middle data layer, and I was having trouble seeing the entire object from within Vue.

This screenshot belongs to console log and it will not contain the API response, the JSON response.
You can see the actual response if you send the request the API using some client, like POSTMAN.

Best way to handle invalid GET/POST request parameters with Flask+Python?

Whats the best way to handle invalid parameters passed in with a GET or POST request in Flask+Python?
Let's say for the sake of argument I handle a GET request using Flask+Python that requires a parameter that needs to be an integer but the client supplies it as a value that cannot be interpreted as an integer. So, obviously, an exception will be thrown when I try to convert that parameter to an integer.
My question is should I let that exception propagate, thus letting Flask do it's default thing of returning an HTTP status code of 500 back to the client? Or should I handle it and return a proper (IMO) status code of 400 back to the client?
The first option is the easier of the two. The downside is that the resulting error isn't clear as to whose at fault here. A system admin might look at the logs and not knowing anything about Python or Flask might conclude that there's a bug in the code. However, if I return a 400 then it becomes more clear that the problem might be on the client's end.
What do most people do in these situations?

HTTP 400 seems good to me.
Returning 500 in this case is wrong. It provides no information to the client, and they will assume that the problem is with the server, not the client.
There is nothing stopping you from adding a body to the 400 response that identifies the parameter with the invalid value (or whatever the problem was). Use whatever representation the client accepts, e.g. if it's an API you might return a JSON response:
{"error": "parameter age: positive integer required"}

If you look at most of the REST APIs, they will return 400 and appropriate error message back to the client if the user sends request parameters of a different type than is expected.
So, you should go with your 2nd option.

A status code of 400 means you tell the client "hey, you've messed up, don't try that again". A status code of 500 means you tell the client "hey, I've messed up, feel free to try again later when I've fixed that bug".
In your case, you should return a 400 since the party that is at fault is the client.

Custom abort mapping/exceptions in Flask

The default message for Flask 400 exception (abort()) is:
{
"message": "The browser (or proxy) sent a request that this server could not understand."
}
For 404:
{
"message": "The requested URL was not found on the server. If you entered the URL manually please check your spelling and try again. You have requested this URI [/obj/] but did you mean /obj/ or /obj/<int:id>/ or /obj/<int:id>/kill/ ?"
}
I have trouble comprehending these messages when I'm getting them as replies in my API (especially the first one, I thought there's something wrong with encryption or headers) and I thing it's kinda tiresome to try to override text manually for every abort() exception. So I change the mapping:
from flask import abort
from werkzeug.exceptions import HTTPException
class BadRequest(HTTPException):
code = 400
description = 'Bad request.'
class NotFound(HTTPException):
code = 404
description = 'Resource not found.'
abort.mapping.update({
400: BadRequest,
404: NotFound
})
For the case of 400 it works beautifully. But when it comes to 404 it is still the same message. I tested it in the same place in my code - it works for abort(400), abort(403) and some of the others, but it gets mysteriously overridden by default message on abort(404). Debugging didn't help much. What may be the culprit here?
Update. Yes, I'm using abort imported from flask not flask_restful as the latter doesn't have the mapping and it's a function not an Aborter object. Besides, it does work for most exceptions, so it's probably not the real issue here.
Update 2. The abort.mapping seems to be perfectly fine on execution. The exceptions in question are overridden, including 404.
Update 3: I've put together a little sandbox, that I use for debugging. (removed the repo since the mystery is long solved).

It took me some time, but now I actually found the place, where it all derails on 404 error. It's actually an undocumented feature in flask-restful. Look at the code here. Whatever message you chose persists until that very place and then it becomes the default. What we need now is just put ERROR_404_HELP = False to our config and everything works as intended.
Why is this code even there in the first place? OK, perhaps, I can live with that, but it should be all over the documentation. Even when I googled the name of the constant, I only got a couple of GitHub issues (1, 2).
Anyways, the mystery is officially solved.

By the way... I can't point to documentation for how I discovered this, I just tried it (that's how I learn most development!) but, you can simply abort with the desired response code but instead return a custom string with it. I think this makes sense because you're using the framework the way it's intended, you're not writing tons of code, you're returning the correct response code and in the fashion the framework expects, and you're informing any human who reads it as to the application's context for the error.
from flask import abort
abort(404, "And here's why.")

Web service that returns any http status code you specify for API testing purposes?

A few months ago I remember reading about a useful little web service somebody put together for API testing purposes. Basically, you just did a call like this, e.g.:
http://www.someAPItestingtool.com/status/405
And the server would respond with a 405 / Method Not Allowed.
It was basically just a handy little utility you could use during development if you just wanted to interact with a live URL that behaved the way you specified.
My google-fu is weak today and I cannot for the life of me remember what it was called. I'm sure I could whip something like this up myself in about as long as its taken me to type this question, but if anybody remembers what I'm talking about, perhaps you can share?
Many thanks...
Edit: Posted something I whipped up real quick, but I'd still be interested in the answer if someone knows what I'm referring to...

Over a year later, I at last re-stumbled upon the service I was thinking about:
http://httpstat.us/

I'm still quite positive someone put something like this together, but it was quicker for me to just whip up something using Flask:
from flask import Flask, make_response
app = Flask(__name__)
#app.route('/<int:status_code>')
def return_status(status_code):
response = make_response()
response.status_code = status_code
response.data = response.status
return response
if __name__ == '__main__':
app.run()