NON-GET links with query parameters

22 views
Skip to first unread message

Icke Bins

unread,
Oct 31, 2021, 10:00:46 AM10/31/21
to HAL Discuss
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

unread,
Oct 31, 2021, 1:14:56 PM10/31/21
to hal-discuss@googlegroups com
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

unread,
Oct 31, 2021, 2:29:55 PM10/31/21
to HAL Discuss

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

Evert Pot

unread,
Oct 31, 2021, 7:54:24 PM10/31/21
to hal-d...@googlegroups.com
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

unread,
Nov 1, 2021, 6:50:53 AM11/1/21
to HAL Discuss
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

unread,
Nov 1, 2021, 7:49:49 AM11/1/21
to HAL Discuss
> 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

unread,
Nov 1, 2021, 3:48:31 PM11/1/21
to HAL Discuss

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.
Reply all
Reply to author
Forward
0 new messages