Is it OK to return 404 for this case

Question

We have an API request to post a comment for a company:

POST http://localhost:4249/api/calendar/comments HTTP/1.1
Host: localhost:4249
Connection: keep-alive
Content-Length: 67
Accept: application/json, text/javascript, */*; q=0.01
Origin: http://localhost:4249
X-Requested-With: XMLHttpRequest
Content-Type: application/json

{"CompanyId":"9e21bb54-387e-428a-878b-04cd0f9cc0d3","Text":"company comment text"}

In case there is no company we want to post a comment for at the moment should we return 404 or 400 ?

Also, if we restructure request this way

http://localhost:4249/api/calendar/comments?companyid=9e21bb54-387e-428a-878b-04cd0f9cc0d3
Host: localhost:4249
Connection: keep-alive
Content-Length: 67
Accept: application/json, text/javascript, */*; q=0.01
Origin: http://localhost:4249
X-Requested-With: XMLHttpRequest
Content-Type: application/json

{ "Text":"company comment text" }

should it be better?

The EF classes we have for Company and CompanyComment are:

public class CompanyComment
{
    [Key]
    public Guid Id { get; set; }

    public DateTime CreatedAt { get; set; }

    [Required]
    public string Text { get; set; }

    public string UserId { get; set; }
    public virtual ApplicationUser User { get; set; }

    [Required]
    public Guid CompanyId { get; set; }
    public virtual Company Company { get; set; }
}

public class Company
{
    [Key]
    public Guid Id { get; set; }

    [Required]
    public string Name { get; set; }

    [Required]
    public DateTime Created { get; set; }
    public string Address { get; set; }
    public string Email { get; set; }

    public virtual ICollection<CompanyComment> Comments { get; set; }
}

Answer 1

For the first question based on the HTTP RFC for 400 code:

The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications.

Note that while the RFC talk about "malformed syntax" usually for an API, the semantic meaning is used, ie is the type of one attribute doesn't match the expected one as declare in the API documentation, eg if the request contain a CompanyId as an integer it make sense to return 400 because you're expectring a UUID

While for the 404 it says:

The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent.

Since is actual error is "the company id given was not found" 404 makes more sense.

As for the second question, The RFC allow both, so the server can accept both or one of them, albeit I'd found odd as a client of a server only accept POST requests with query parameters.

Personally I tend to avoid using query parameter on POST requests because it is easier to expect all parameters to be in the payload. But since URL and query parameters are supposed to define resource vs payload defining action it can make sense.

I'll suggest to use one way to keep consitency though, so either the CompanyId is always in the query or is always in the payload.