[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ProgSoc] REST vs. HTTP in the real world



On Tue, 29 May 2007, James Andrewartha wrote:
> > You wouldn't expect /my-doc?section=2.1 to contain the content of
> > section 2.1 of my-doc?
>
> I would, but it would also contain links to the component resources.
> These could be via <link rel="edit" href=""> tags if it's (X)HTML, or
> RDF, or XLink or whatever other linking method is appropriate.

Do you think that the relationship between everything that can be named 
in your problem domain should be given a URI and then have its content 
provide links to everything else to which it is related? (Hint: because 
that would be absurd.)

> I'm saying ?section=2.1 is part of your higher business logic that's
> deciding how sections are numbered.

I can't interpret your statement. Sounds like... nothing.

> You've gone and put your business logic into the URL, which is why
> CRUD on it doesn't make any sense.

What?

> > You might explain what justification you have for such thoughts?
>
> Cacheability is obvious.

Actually, I'm finding it very difficult to understand how you think 
that 'cacheability is obvious' is even a sentence, let alone how it 
might bear on a discussion concerning the HTTP verbs POST, PUT and 
DELETE.

> Cognitive load can be seen from the questions you raise above - you're
> putting business logic into the URLs,

If you say "putting business logic into the URLs" one more time, I'm 
going to be forced to break something. What do you think "putting 
business logic into the URLs" means?

> which means violating layer constraints.

This means precisely nothing to me. You might indicate what you think 
a "layer" is and what constraints apply to it?

> This leads into the flexibility - once your REST layer is written you
> can just throw URIs at it for it to CRUD.

Um, CRUDing URIs only makes sense if you think that URIs represent 
files.









-
You are subscribed to the progsoc mailing list. To unsubscribe, send a
message containing "unsubscribe" to progsoc-request@xxxxxxxxxxxxxxxxxxx
If you are having trouble, ask owner-progsoc@xxxxxxxxxxxxxxxxxx for help.