Re: How to determine the Http Method type being implemented for web service API
Re: How to determine the Http Method type being implemented for web service API
- Subject: Re: How to determine the Http Method type being implemented for web service API
- From: Tito Ciuro <email@hidden>
- Date: Mon, 24 Jun 2013 12:48:16 -0700
Let's not forget about PATCH:
http://tools.ietf.org/html/rfc5789
I'm not sure if it's been ratified already, but it could be around the corner. It's already part of technologies like Node.js, for example.
-- Tito
On Jun 24, 2013, at 11:14, Jens Alfke <email@hidden> wrote:
>
> On Jun 23, 2013, at 11:05 PM, Omkar Ramtekkar <email@hidden> wrote:
>
>> Server side people have implemented a few web services. I need to use those methods, but I'm not sure which http method to use "Get" or "POST”.
>
> If it’s really a RESTful API, then you use GET to retrieve the contents of a resource, and POST to create a new resource (without specifying a URL for it.)
>
> In general, anything that has side effects (i.e. changing the state of the data on the server) cannot be a GET request. And PUT requests only create new resources (at the given URL), and DELETE only deletes resources. So anything that doesn’t fall into those categories is going to be a POST.
>
>> If I use "GET" as http method and if the server web service is being implemented in "POST" then I get 404 or similar http error code.
>> Is there any way to find out the http method type being implemented for a web server API?
>
> Read the documentation of the service, or ask an expert for help. Seriously. HTTP is not self-documenting this way. The answer about looking at the 405 response is correct as far as it goes, and there’s also the OPTIONS method, but both of those will only tell you what methods are allowed on that URL, not what they *mean*.
>
> If you try to implement a client for a web API by guesswork, your code is likely to be fragile and break in the future if any changes are made on the server side. Unless you’re trying to reverse-engineer a proprietary API, you should really really follow the documentation.
>
> —Jens
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden