WWW class support explicit methods (GET, POST, PUT, DELETE)

Hello,

I'd like to request that the built-in WWW support the PUT and DELETE methods along with GET and POST currently supported. These are standard methods that need to be supported in a class designed to interact with an HTTP server.

It will be necessary also to allow the explicit setting of the method to be used (currently, the method is implicitly set depending on the existence of postData). This is a good idea, anyway, as there are times when you may want to do a POST without sending any data.

Examples:

Code (csharp):

1. WWW('http://myserver.com/players', 'post', 'name=Timmer');
2. WWW('http://myserver.com/players/Timmer', 'put', 'gender=male');
3. WWW('http://myserver.com/players/Timmer', 'delete');
4.  

 

If you check this out:

http://forum.unity3d.com/viewtopic.php?t=18846

You will see all that functionality is available. Those commands are just executed on the server via PHP, instead of directly connected with the WWW class.

 

Tempest,

Thanks for your link!

However, your code, at least how I see it, is not actually using the HTTP actions PUT and DELETE. Instead all the actions use the WWWForm -- with custom fields -- which the WWW class sends with a POST to the server.

This is definitely useful but it is not the same as using the HTTP methods above so I'll stand by my wish list

 

Timmer -

That is a good request. Unfortunately, since browsers never really learned to support PUT and DELETE, most RESTful APIs make due with GET and POST. The problem becomes a bit self-fulfilling in that APIs are written to require only GET and POST since most clients only support them, but supporting PUT and DELETE isn't a priority when developing a client since few APIs require them. I've lamented this more than once.

You can certainly design things so that they can make due with POST (or variables passed with GET... which sort of makes me shutter a bit), but there are a number of benefits to actually supporting PUT and DELETE, not the least of which is that by including those two, you free up GET and POST to do what they were intended and can actually use your HTTP methods to specify the operation rather than over-designing a system to handle it. And that isn't saying anything about some of the other benefits -- those two methods are idempotent, which POST is not, for example. Designing a comparable system around just GET and POST is a hassle.

 

Seems we all have bumped into the 'REST wall' and struggled with it.

And that's because we deal with the server-side solutions (Drupal in my case) that we have no influence in. And they are doing their REST thing based on the 'old' specifications, dealing with PUT and DELETE to enable the update and delete CRUD operations.

Looking at the RESTServer.inc file (the resolveController method) you can see the decision making based on the REST method plus number of link variables.

But, there is a good news: all you need is possible to accomplish using GET and POST only:

1) GET for retrieving (indexing) multiple nodes (i.e. lists), and also for retrieving a single node (by transmitting not-dangerous-to-see data inside the link variables, that can be be indexable, seen written inside the server logs etc.)

2) POST for creating, updating, and deleting, plus all other custom actions (for 'sensitive' data)

However, some server-side systems seem not to support this 're-routing' without your intervention in code (e.g. custom modules). Here's an excerpt from Drupal's 'user_resource.inc' module:

PHP:

function _user_resource_definition() {
  $definition = array(
    'user' => array(
      'retrieve' => array( // GET ...
      'create' => array( // POST ...
      'update' => array( // PUT ...
      'delete' => array( // DELETE ...
      'index' => array( // GET ...

Those actions are reachable strictly using the given (GET, POST...) operations. You can play with it using the Firefox Poster.

But, looking more carefully into the code, you struck gold:

PHP:

      'actions' => array(
        'login' => array(... // POST

Bingo! So, there's a special kind of operations that are fully customizable, and they play by your own rules (though in POST fashion). Similar to 'login' action in the user module, you can implement your 'delete' action, or 'gimme_top_10_players' action in your own module.

Hope this helps someone...

Danko Kozar

 

Hi everyone,

I would like to bump this thread since this problem is still very present and that there exists many scenarios that aren't easily solved by the man in the middle approach.

Here's the problem we want to solve:

My team is heavily invested in the Azure platform and would like to use the Service Bus as a facilitator for client to client communications. The Unity project we are working on allows for low latency game updates such as broadcasting the state of game objects from one player to potentially very many players. The Service Bus seems like a very lean and scalable solution for Indie/MVP size games to that end.

However, since we can't get Unity to make DELETE requests this solution will not work given that the Service Bus only supports standard HTTP/1.1 and no hacks. The man in the middle approach will not work since that will add latency and will diminish the scalability benefits both in terms of sheer volume and geographical spread.

We will have to choose another path as it seems right now; considering changing service provider as well as changing game engine, both with huge trade-offs.

Not supporting a HTTP/1.1 seems backwards since it became a standard in 1997. Saying that we should all be lazy since everyone else is doesn't make much sense since since the day of it's official release a strong majority of browsers were supporting it already.

Best regards,
Martin Svensson

 

Don't forget about UniWeb. It does all this and more.

http://u3d.as/content/different-methods/uni-web/1Cw

</shameless plug>

 

Thank you Simon for pointing that out. We are one happy customer since a few weeks back.

We had to struggle a bit with keep-alive since we're barraging over https but the asset store says you support it now which is very promising.

Keep up the good work!

 

Hello does your product support Android as well as iOS? I'm having great difficulty finding a product that works on all targets.

Thank you.