#POST is not possible
15 messages · Page 1 of 1 (latest)
What's the body of the http response?
How are you making the request to the server? That error is indicating there's a problem in the multipart form data.
I don't know. I don't understand your questions. You shouldn't be having to write the actual body.
You're referencing things I'm not expecting to see. What is "Content"?
Hmm. Seems like an issue with the browesable api then
Have you tried making a submission with something else?
Okay, it's definitely an issue with the browesable api then. Maybe check the projects issues to see if someone else has run into this?
I just tried it on my backend, when I make a POST request as a mutlipart/form-data without the body (with an empty Content field) it returns:
{
"name": [
"this filed is required"
]
}
error, however if I POST some Content formated the same way as JSON:
{
"name": "John"
}
it return the same error you have:
{
"detail": "Multipart form parse error - Invalid boundary in multipart: None"
}
In Postman you're probably using those form fields with separated name and value and it just works, therefore I guess the format of mutlipart/form-data differs from JSON, but I can't find what's the correct way to make that request as mutlipart/form-data.
# it might be this:
name: John
# or this:
"name": "John"
# or this:
name="John"
I hope you get the point
Btw. this part:
# プロジェクト情報をシリアライズ
serializer = ProjectSerializer(project)
makes no sense by itself.
And lastly ChatGPT is way better than Google as a translator.
I looked how Insomnia (API tool like Postman) represents multipart/form body and copied it to Content:
--X-INSOMNIA-BOUNDARY
Content-Disposition: form-data; name="name"
John
it returns this time:
{
"name": [
"this filed is required"
]
}
so boundary separates each name-value (in this case there is only one),
good luck trying to figure out what's the proper format. I would ask on GitHub, it should be documented but once again I can't find anything.
If you want to use DRF Browsable API, you can use Media type as application/json with JSON as Content:
{
"name": "John"
}
and it should work either way (although I'm not sure how that redirect will behave), and on the fronted use a form.
I would have a few issues. There's project_name and potentially just name (see your __str__ method). Those will be confusing.
Regarding task_name and branch_name, I think those may be better off as a separate models that you have ForeignKey fields to.
You should rename Task.task_name to Task.name and Project.project_name to Project.name
I don't fully understand what real-life concept you're trying to data model. I think the above is better, but I don't know if you should continue normalizing.
Depends on what you mean by correct.
My gut tells me it's a mistake, but you know more about your problem than me.