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.
Also, the current spec allows a server to use the same URI for Full and
Filtered Map services. Eg, consider this IRD fragment:
"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
