Request a topic or
contact an Arke consultant
404-812-3123
December 2010

Arke Systems Blog

Useful technical and business information straight from Arke.

About the author

Author Name is someone.
E-mail me Send mail

Recent comments

Archive

Authors

Disclaimer

The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2017

HTTP: PUT vs POST

PUT doesn’t come up much with plain html work.  Pages and forms pretend that everything is a get or a post.  But once one is working with web services, your choices are:

SOAP – send everything as an HTTP POST.  HTTP is being used mainly to dodge firewalls and not really providing any benefit.  Protocol was intentionally designed to be too complex for humans, leading to dependence on tools.

REST – use verbs applied to nouns.  HTTP has other useful verbs besides GET and POST. 

Unfortunately, PUT is conceptually similar so easy to get confused.  I thought I’d mention here in one spot the two key differences:

a) PUT is indempotent.  Repeating the same operation should get the same result.  Side effects are allowed, but the side effects should be the same for repeated requests.  POST is not indempotent.  Repeating the same operation may yield different results.

b) PUT contains the actual item for a specified resource.  POST provides an item for the specified resource to work with.

For a practical example, POST would be used to tell an account to add a new note to it, while PUT would be used to edit the contents of a note.  PUT can’t do an “append” operation, if you POST your ‘add a note’ twice you have two notes, if you PUT the same note twice you just have the one note in the end.

I think it’s really important to consider both of these things together – the side effects are different, and the entity you specify are different – PUT says “this resource is this data”.  POST says “this resource should work with this data”.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html for a primary source


Posted by David Eison on Wednesday, December 8, 2010 2:40 AM
Permalink | Comments (0) | Post RSSRSS comment feed

CRM entity browser appears unreliable

CRM has this nice entity browser that is supposed to show you info about your entities, like what fields there are and how long they can be.  You go to your server and add /sdk/list.aspx to the url and it shows you what entitites you have and what their attributes are.

I used to rely on it because as a programmer, it’s the quickest/most convenient way to get the length information and the ‘valid for update’ information about fields.  Unfortunately, it’s apparently unreliable.

The below screenshot is from a client site. They only have 1 CRM organization configured, yes I’m pointing to the right server on both, and yes their contact is published.  But the entity browser does not show that the fields have had their sizes reduced (to better fit on mailing labels), and if I relied on this to write my code for working with addresses, I’d get it all wrong.

SNAGHTML381e91c


Posted by David Eison on Friday, December 3, 2010 12:16 PM
Permalink | Comments (0) | Post RSSRSS comment feed