Wendy,
> On 17 Jul 2014, at 16:00, Wendy Roome <[email protected]> wrote:
>
> Ben,
>
> However, if a significant number of ALTO servers accept POST as well as
> GET for full map services, that will establish a de-facto standard, and it
> will be difficult to define different semantics for POST in the future.
Not really as the semantics can be defined in terms of the Content-Type of the
POST.
> Also, the current spec allows a server to use the same URI for Full and
> Filtered Map services. Eg, consider this IRD fragment:
Good point - for some cases the semantics of POST are defined.
For cases where the semantics of POST to a URI are not communicated as part of
the IRD or some other out of band means I could live with saying the ALTO
server SHOULD return an error (but I don't think we should define the precise
status code).
Ben
>
> "my-default-network-map" : {
> "uri" : "http://alto.example.com/networkmap";,
> "media-type" : "application/alto-networkmap+json"
> },
> "filtered-network-map" : {
> "uri" : "http://alto.example.com/networkmap";,
> "media-type" : "application/alto-networkmap+json",
> "accepts" : "application/alto-networkmapfilter+json",
> "uses": [ "my-default-network-map" ]
> },
>
> That says that for http://alto.example.com/networkmap, GET returns a full
> network map, while POST (with the appropriate content type) returns a
> filtered network map.
>
> - Wendy Roome
>
>
>> On 07/17/2014, 03:39, "Ben Niven-Jenkins" <[email protected]> wrote:
>>
>> Wendy,
>>
>>> On 16 Jul 2014, at 16:10, Wendy Roome <[email protected]> wrote:
>>>
>>> Here is a fringe case that doesn't seem to be covered in the protocol
>>> spec.
>>>
>>> If a client sends a POST request to a GET-mode service, like Full Cost
>>> Map, should the ALTO server reject the request? Or should the server
>>> accept the request anyway, and just return the map?
>>>
>>> And would it depend on the content the client sent? Eg, should the
>>> server
>>> accept a POST request with no content, but reject a POST request if the
>>> client sent a body of (say) type application/alto-costmapfilter+json, on
>>> the grounds that the client mistakenly thought this was a Filtered Cost
>>> Map service?
>>>
>>> My inclination is to reject an POST request, even if there is no
>>> content.
>>> Normally I prefer to forgive obvious errors, but unless all servers have
>>> the same level of forgiveness, error-tolerant servers will be seen as
>>> "correct", while other servers will be seen as "incorrect".
>>>
>>> What does the group think?
>>
>> My view is that the behaviour is server implementation specific and that
>> clients must not rely on a particular response unless they have further
>> information to suggest otherwise.
>>
>> I don¹t like the idea of mandating returning an error as I¹d like to leave
>> the door open to allowing POST later on, e.g. as a possible means to
>> update
>> the map.
>>
>> Ben
>
>
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
