Home
i finally posted (googelcode, codeplex) my first pass at a deployment tool (SSDSDeploy.exe) for posting binary files to your SSDS stores. it's now possible to upload one or more files (using wildcards or command-line scripts) to any designated SSDS /authory/container location. below is the 'help doc' for this command-line app:
SSDS Deploy Console (1.0 - 2008-08-18)
POST single binary file:
/{a}/{c}/{e} "[c:][\folder\path\]file.ext" ["mime-type"] [y]
where:
{a} = authority
{c} = container
{e} = entity
y = overwrite existing entities
ex: /my-auth/files/my-profile "c:\temp\profile.jpg" "image\jpeg" y
POST multiple files using wildcard:
/{a}/{c}/* "[c:][\folder\path\]*.*" [y]
ex: /my-authority/my-container/* "c:\uploads\*.*" y
or
ex: /my-authority/my-container/* "c:\images\*.png" y
in this release you can POST (including overwrite) to the /authority/container/ store using a simple filename (filename.ext). currently SSDS has trouble parsing entities w/ "/" and/or "\" in the name. for now, that means you can't upload using an entity name such as /images/file.png. but you *can* use file.png. while SSDS is working on this bug, i may release a version of the tool that uses some other URL-safe character as the 'folder-separator' (":"?).
i recently got a question on why i've not rev'd the exyus codebase in months. good question.
first, i started to slow on changes to the codebase this spring. i'd reach most of my initial goals of building a REST-y library for IIS w/ C# and began focusing on exercising the details. that allowed me to flush out weak spots, find holes in the implementation, etc. and besides, i was kinda tierd of writn C# and more interested in building web apps[g].
along the way, i got side-tracked by SSDS. SSDS is MSFT's implmentation of database services 'in the cloud.' in this case, they support basic data read/write via SOAP and a REST interface. i've only worked with the REST interface and it's pretty solid. so, over the last two months i've been putting out demo apps and posting my code for other to play with. i'll also point out it's a great beta program. the SSDS team is a good bunch and they are pretty active on the MSFT-hosted SSDS forum.
so...
i cut back on rev-ing exyus to take time to use it and i started working with a new data storage system that uses REST as an interface. the next logical thing would be to combine the two, eh? it would be pretty simple. i just need to implement a single class within exyus that does the read/write work against SSDS. the main issue is that, right now, SSDS is quite constrained in it's feature set. it's an early beta. but i have it on my list of things to do.
finally, now that i've used exyus as a web library for a while, i can areas where it can be improved, expanded, and (most importantly) where code can be removed (remember: Code is our enemy). over the next month or so, i'll get back to updating the exyus source code. and when i do, it should be smaller, faster, and better able to handle typical workflow of a web application.
in the last few days, Bill de hÓra has posted some incredible stuff on REST-related issues.
i'm blown away.
thanks.
i read REST, I just don't get it today and just had to hang my head.
there is so much of REST that folks don't get. but saying:
...just use a POST as an RPC call, keep it as simple as possible and be done with it. And don't spend another minute worrying about being RESTful or not.
is just wrong.
while i see lots of 'hey, you put a VERB in the URL!' or 'You're lame if you don't use PUT' kinda talk, i don't see folks talking about some of the most important concepts outlined in Fielding's 1999 dissertation, Architectural Styles and the Design of Network-based Software Architectures - the document that described for the first time (in Chapter 5) what REpresentational State Transfer was about. check the year - 1999. actually, first drafts of the REST model were written as early as 1994! Fielding was part of the team that outlined the massively scalable distributed-networking protocol known to us as HTTP. Fielding was there on the ground floor. his REST model, even almost a decade after it's official release, stands as one of the best attempts to codify some of the key architectural patterns that went into designing HTTP.
and there are several
- Use of separation of concerns via the Client-Server style
- Stateless, self-descriptive messages supported by meta-data
- Support for cache-ability including third-party intermediaries
- A stable, uniform interface understood by all parties.
- A layered, multi-party network where everyone can work safely without having to understand every detail of a transaction
- Support for portable code-on-demand that allows servers to send executable units to clients for local execution
and add to the above vital system-wide constraints these additional patterns so common today we hardly give them much thought:
- the abstraction of Resource Identifiers and Resources (via URIs)
- the abstraction of the Resource and it's Representation (via MIME-types)
- the abstraction of process flow and resource discovery (via Hypermedia links)
- the abstraction of resource access, transfer, and processing (via a single abstract interface) that allows clients, proxies, servers, caches, resolvers, and other agents to work safely together
that's quite a bit of work. quite a bit of *important* work. important work that, even after a decade (almost a century in 'Internet years') continue to thrive, grow, change, and adapt to include new media types, new authentication schemes, and more.
finally, you should note that this rant does not address the 'REST means you *MUST* use PUT and DELETE methods' or 'REST means you can't use a *VERB* in the URI' assertions. that stuff just misses the point. REST is much more than rules about URLs and HTTP method calls.