<br><br>On Friday, September 14, 2012, Glen Daniels wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 9/13/12 11:25 PM, Douglas Campos wrote:<br>
> Howdy!<br>
><br>
> I was thinking on how to start this conversation on server contracts, so let's start with an example for a resource named "car" - all interactions are 'application/json'.<br>
><br>
> We talked on irc about how to maintain the bare minimum that would give us full agnostic server backends, and I've tried to limit as CRUDL - CRUD + List without pagination :)<br>
><br>
> C POST /cars<br>
> R GET /car/1<br>
> U PUT /car/1<br>
> D DELETE /car/1<br>
> L GET /cars<br>
><br>
> Glen commented on irc that this would introduce coupling between the client and the server - but the point is that the endpoint style can and should be configurable in several levels:<br>
><br>
> - always_plural? (/cars everywhere) [1]<br>
<br>
+1. I don't think we should initially even care abut the above case,<br>
but only support "/cars" and "/cars/1".<br>
<br>
> - do we support batch operations? (as suggested by [1])<br>
<br>
By "batch" do you mean PUT to "/cars" to bulk-update the whole<br>
collection? I don't think we need to do that initially either, as most<br>
REST APIs I've seen don't support that.<br>
<br>
> - logic name (/vehicles should be interpreted as "cars")<br>
<br>
No need to do anything explicit about this, if I'm understanding you<br>
correctly. Taking a Java/Android example, if you want to play with<br>
cars, you could just do:<br>
<br>
pipe = new Pipe("vehicles", Car.class);</blockquote><div><br></div><div><br></div><span class="Apple-style-span" style>vehicles is a logical name on the client, for the /cars resource (due to the Car type), right?</span><div>
<span class="Apple-style-span" style><br></span></div><div><span class="Apple-style-span" style><br></span></div><div><span class="Apple-style-span" style>I tought he meant endpoint aliases <br></span></div><div><div><span class="Apple-style-span" style><br>
</span></div><div><span class="Apple-style-span" style>-M<span></span></span></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
In other words, specifying the URL for a given collection's root is up<br>
to the dev.<br>
<br>
> - read-only routes?<br>
<br>
Not sure what this means? Certainly authorization is a factor here.<br>
<br>
> The point is, we can and should adapt to the most common scenarios - so an user should be able to use /signup instead of /register for auth endpoints - and there's what is a must for us IMO.<br>
<br>
...yes, but that still assumes that you send the same piece of JSON to<br>
your auth endpoint, right? Or perhaps "username"/"password" form fields<br>
- but of course some of those also need a "passwordConfirm" param... or<br>
maybe a "confirmPassword" param... or OAuth... and that's when I think<br>
you start getting into hairy stuff.<br>
<br>
> The user is using a <insert your technology here> server? if he supports http sessions we should be able to authenticate him, and here is where our challenge lies - being "inclusive" without making our APIs lame :)<br>
><br>
> So, we need to figure out what is more common, and make this the default (or convention), while still allowing our users to choose different/weird conventions for their endpoints.<br>
><br>
> Thoughts?<br>
<br>
Challenging.<br>
<br>
> (Before I forgot, Glen asked about pagination too, and I think this should be layered on top of this basics, as in this case there is no standard way to do it)<br>
<br>
Like security, there are a few best practices / common patterns here<br>
too. Examples:<br>
<br>
<a href="http://stackoverflow.com/questions/924472/paging-in-a-rest-collection" target="_blank">http://stackoverflow.com/questions/924472/paging-in-a-rest-collection</a><br>
<a href="http://stackoverflow.com/questions/776448/pagination-in-a-rest-web-application" target="_blank">http://stackoverflow.com/questions/776448/pagination-in-a-rest-web-application</a><br>
<a href="http://tools.ietf.org/html/rfc5005" target="_blank">http://tools.ietf.org/html/rfc5005</a><br>
<br>
--Glen<br>
<br>
_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="javascript:;" onclick="_e(event, 'cvml', 'aerogear-dev@lists.jboss.org')">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
</blockquote></div><br><br>-- <br>Sent from Gmail Mobile<br>