NON-GET links with query parameters

[Icke Bins]

Hi,

should a resource offer links with query parameters although the resource supports not the GET method for this link? 

href=/foo/{id}{?name}

But the server only implements like this:

POST /foo/{id}

name=...

Thx

[mca]

Is this a trick question?

--
You received this message because you are subscribed to the Google Groups "HAL Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hal-discuss...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/hal-discuss/c8b2aad2-0021-42dc-8fda-3cc7af8c9013n%40googlegroups.com.

[Icke Bins]

No, since imho query params should be used not for POST.

[Evert Pot]

On 2021-10-31 14:29, Icke Bins wrote:

>
> No, since imho query params should be used not for POST.

That's a misconception. You can POST to any URI, and URIs can have query
parameters.

[Icke Bins]

Yes, you can... but should you? The HTTP Standard is quite vague how to handle non GET requests with query params.

It becomes difficult if your link has a related HAL-FORM.

link:

  href=/foo/{id}{?name}

template:

  method: post

  contentType : application/x-www-form-urlencoded

  properties: [{"name": "name"}]

  target: .../foo/{id}{?name}

This might lead to a request with the query param name and the body param name where the server has to decide how to handle it (Query over Body, Body over Query, both) 

POST /foo/{id}/?name=...

name=...

Solution could be that the templates target is only .../foo/{id}

[Oliver Drotbohm]

> This might lead to a request with the query param name and the body param name…

Yes, and I fail to see why that'd be a problem. It might not be the most user-friendly way of designing an API, but that's in the realm of the designer. There's no problem on the HTTP level at all.

> … where the server has to decide how to handle it (Query over Body, Body over Query, both)

Who or what is "the server" here? One is a request parameter, the other is a field in the request body. If you as a designer of an API choose your URI and representation arrangement like this, it's also you who has to give an answer to this question.

It feels like we're stretching the boundaries of the scope of this list here, too. I try to avoid templating URIs of state transitions, especially if the client had to expand those templates using values from the representation the server just sent them. If that's the case, why not expand the URI on the server already?

Cheers,

Ollie

[Icke Bins]

Sorry, my mistake. The {id} would be of course already expanded in the link.

So the question is:

Should we return a link like 

href: .../foo/1

or 

href: .../foo/1{?name} 

In my opinion .../foo/1{?name} is wrong because the query part is not part of the resource identifier, the path already identifies the resource foo with id 1.