Fwd: New Version Notification for draft-amundsen-richardson-foster-alps-01.txt

342 views
Skip to first unread message

mca

unread,
Mar 2, 2015, 12:43:13 PM3/2/15
to api-...@googlegroups.com
The updated I-D for ALPS was just posted it to the IETF tracker (see details below). I've also updated the web site[0] . 

We're looking for any/all comments and feedback. Feel free to discuss on the ALPS list[1] or here, and to open/update issues in github[2] for the next round of changes. 

---------- Forwarded message ----------
From: <interne...@ietf.org>
Date: Mon, Mar 2, 2015 at 12:23 PM
Subject: New Version Notification for draft-amundsen-richardson-foster-alps-01.txt
To: Mike Amundsen <m...@amundsen.com>, Leonard Richardson <leon...@segfault.org>, "Mark W. Foster" <m...@fosrias.com>



A new version of I-D, draft-amundsen-richardson-foster-alps-01.txt
has been successfully submitted by Mike Amundsen and posted to the
IETF repository.

Name:           draft-amundsen-richardson-foster-alps
Revision:       01
Title:          Application-Level Profile Semantics (ALPS)
Document date:  2015-02-28
Group:          Individual Submission
Pages:          27
URL:            http://www.ietf.org/internet-drafts/draft-amundsen-richardson-foster-alps-01.txt
Status:         https://datatracker.ietf.org/doc/draft-amundsen-richardson-foster-alps/
Htmlized:       http://tools.ietf.org/html/draft-amundsen-richardson-foster-alps-01
Diff:           http://www.ietf.org/rfcdiff?url2=draft-amundsen-richardson-foster-alps-01

Abstract:
   This document describes ALPS, a data format for defining simple
   descriptions of application-level semantics, similar in complexity to
   HTML microformats.  An ALPS document can be used as a profile to
   explain the application semantics of a document with an application-
   agnostic media type (such as HTML, HAL, Collection+JSON, Siren,
   etc.).  This increases the reusability of profile documents across
   media types.

Editorial Note (To be removed by RFC Editor)

   Distribution of this document is unlimited.  Comments should be sent
   to the IETF Media-Types mailing list (see [1]).




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


Owen Rubel

unread,
Mar 10, 2015, 12:30:34 AM3/10/15
to api-...@googlegroups.com
Does ALPS require hardcoding url mapping server side (like HATEOS)?

mca

unread,
Mar 10, 2015, 12:48:18 AM3/10/15
to api-...@googlegroups.com
IIUYQ, the answer is "no".

ALPS does not make any requirements on URLs. since the same ALPS profile is expected to be a viable  for multiple protocols such as XMPP, WS, HTTP, even SOAP over HTTP, etc. where public addressing of operations is done very differently (e.g. as mere port/end-points, as semantically rich RPC calls, as object-style resources, as hypermedia controls within a message, etc.

does this help?



--
You received this message because you are subscribed to the Google Groups "API Craft" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+...@googlegroups.com.
Visit this group at http://groups.google.com/group/api-craft.
For more options, visit https://groups.google.com/d/optout.

Owen Rubel

unread,
Mar 10, 2015, 8:33:21 AM3/10/15
to api-...@googlegroups.com
No not really. If you are saying you don't rely on URL's, how does one implement in a MVC framework to handle mappings for the API's?

mca

unread,
Mar 10, 2015, 11:41:07 AM3/10/15
to api-...@googlegroups.com
ALPS does not make any *requirements* on URLs -- that does not mean service implementors do not *use* URLs when the create a service based on an ALPS profile.

"how does one implement in a MVC framework to handle mappings for the API's?" you can do this any way you wish. ALPS does not constrain implementations' use of URLs. Your URLs are yours. 

ALPS is designed to share common understanding across multiple implementations. for example an ALPS "todo" profile would contain all the data elements (title, id, completed) and actions (new, edit, markComplete, remove, listAll, listActive, listCompleted, clearCompleted) for the service.  Basically ALPS can be a machine-readable version[0] of the human-readable TodoMVC functionality spec[1]. 

You can also think of ALPS as a machine-readable version of Eric Evan's "BoundedContext" -- the things that a service shares w/ the "outside world"

Feel free to drop in on the ALPS list[2] if you want to discuss this more.





Owen Rubel

unread,
Mar 10, 2015, 2:44:32 PM3/10/15
to api-...@googlegroups.com
Ok , I don't want to argue semantics. Let's just see if I have it straight... While the spec doesn't require for CLIENT requests, URL's are how it's implemented SERVER SIDE. 

Hence state is maintained SERVER SIDE by mapping the URL's when it is implemented... correct?

Mind you, I'm not talking CLIENT SIDE. Talking about SERVER SIDE state.

mca

unread,
Mar 10, 2015, 3:05:16 PM3/10/15
to api-...@googlegroups.com
Owen:

I don't think we're arguing here but I do think I am failing to successfully describe what ALPS aims to provide. 

ALPS is not a runtime format like HTML or HAL
ALPS is not a designtime format like RAML or Swagger

ALPS is a Profile format for describing the bounded context of a service. 
ALPS can be used as source material for designtime formats like RAML, WADL, Swagger, WSDL, etc. on the server side.
ALPS can also be used as source material for client-side frameworks like Ember.js, Angular, etc on the client side.

ALPS describes the operations (actions) and data elements of a service. that's all. that description is the same no matter the designtime tooling, protocol, or message format used. that description is the same whether you are implementing code on the client-side or server-side. 

"Hence state is maintained SERVER SIDE by mapping the URL's when it is implemented... correct?" 
ALPS has nothing to say about how or where state is maintained. You can do whatever you wish when you implement the bounded context ALPS describes.

ALPS tells you the WHAT of the service, not the HOW. 

for example, you can use the ALPS document to implement a services that employs your API Chaining on the server side. Or you can use the same ALPS document to implement a classic hypermedia-driven service using Cj or some other hypermedia-rich format. You can also use the same ALPS document to implement a simple JSON-object CRUD-style service. 

When you use ALPS as the "shared bounded context" you can be confident that each of the services, regardless of their local implementation choices are supporting the same bounded context. this is especially handy when you want to provide the same operations using different implementations (e.g. JSON-object CRUD for mobile, HTML for browser, etc.).

better?

anyone else want to chime in here and maybe help sort this out? by being so *into* this model, I may be skipping over fundamental elements and missing an oppty to explain this better.








Owen Rubel

unread,
Mar 10, 2015, 3:19:51 PM3/10/15
to api-...@googlegroups.com
Ok misunderstanding... I assumed the data RELATED to a URI/URL. So you are saying the data doesn't require a URI/URL

Interesting. I'm checking it out right now, I may be able to use this someplace. :)

mca

unread,
Mar 10, 2015, 3:21:25 PM3/10/15
to api-...@googlegroups.com
cool. sorry it took me so long to explain.

c'mon over to the list and let's discuss.

cheers.




Owen Rubel

unread,
Mar 10, 2015, 3:36:16 PM3/10/15
to api-...@googlegroups.com
Yeah not trying to argue, just frustrated that I'm not being clear.

So I read through it... and in the context of API's, the spec DOES require a URL/URI; Not because your spec requires it but because API functionality requires it.

And thats what I think was where the confusion lied; what I was asking vs what you were saying.

The spec doesn't REQUIRE URL's but if you implement an API with ALPS, you're ARE going to HAVE to use URL's with it simply because the functionality of an API requires it.

If you DON'T, ALPS becomes the point of failure. So the URL IS REQUIRED... but only in the sense that we are talking about API's.

So is this a multi-purpose format?

mca

unread,
Mar 10, 2015, 3:45:25 PM3/10/15
to api-...@googlegroups.com
ok, you want to continue talking here....

1) you can use ALPS to implement a service that exposes a bounded context via COM/DCOM/CORBA/RMI or even just passing message along a queue. no URLs *required* for that. IOW, none of this has to travel over the Internet. It could travel over local TCP/IP between components. In fact, this is a very solid use of ALPS for Erlang, and other message-driven languages.

2) if you *do* implement something that uses RFC3986-style addresses, the size and shape of them is totally up to the implementation. you can use a single URL for all operations (ala WebSockets), bury operation identifiers in query params (ala SOAP), use semantically meaningful URLs (ala CRUD), etc. ALPS does not dictate the shape or use of URLs and that is why there is nothing in the ALPS spec to suggest the use of URLs.

"If you DON'T, ALPS becomes the point of failure." -- i have no idea what that means or why you'd say it.





Owen Rubel

unread,
Mar 11, 2015, 10:24:22 AM3/11/15
to api-...@googlegroups.com
Right so thats what I was asking. You have to supply the URL mapping Server side and in the spec for API (regardless of SOAP/REST/etc) a URL/URI is 'NEEDED' (notice I didn't say REQUIRED as that seems to be a sticking word). Correct?

And what I was saying was that since you were saying one isn't REQUIRED (I was hoping to avoid arguing semantics), one is NEEDED by functionality. Therefore if one isn't SUPPLIED, it becomes the point of failure.

HOWEVER... proper checking on REQUIRED data could be done. But these are not REQUIRED. If they were REQUIRED for API's, a proper check could be done.

In functionality SERVER SIDE, one has to just KNOW this check has to be done.

You see what I'm saying?

mca

unread,
Mar 11, 2015, 10:58:52 AM3/11/15
to api-...@googlegroups.com
"You see what I'm saying?" -- probably not.

"You have to supply the URL mapping Server side " -- I suspect you mean to say "when the service implementation relies on URLs, those URLs will need to be provided by the service implementation" which has been the case since the first service implementation ever rose up from the primordial slime. 

"Therefore if one isn't SUPPLIED, it becomes the point of failure." -- yes, if the service that depends on URLs does not provide URLs then that service will not work -- that's a fail, i guess. 

certainly neither of these points is anything new. i don't see how this is related to the ALPS spec i introduced in this thread. what have i missed?

"HOWEVER... proper checking on REQUIRED data could be done. " -- i have no clue what this is about.



Owen Rubel

unread,
Mar 11, 2015, 10:34:48 PM3/11/15
to api-...@googlegroups.com
if a url isn't supplied in the spec for the serv side implementation to map to, it fails. I apologize if this is frustrating but this is a two part equation and it seems like only client side is being addressed when the server side part creates a requirement as well.

There are two states: client state and server side state. Both have to be maintained separately but both rely on the information SYNC'ing.

The synchronization of this information is handled in your spec but what I am sayign is if there is no URL requirement, server side will no KNOW to require the information because there will be nothing to check against as it is not 'required'

mca

unread,
Mar 11, 2015, 10:51:18 PM3/11/15
to api-...@googlegroups.com
<snip>
if a url isn't supplied in the spec for the serv side implementation to map to, it fails.
</snip>

ohhh....
you think the URL is *missing* from ALPS.  and, since it is missing ALPS fails.

ok, i've clearly failed to convince you that ALPS provides value for services even though ALPS allows service providers to determine their own URLs. no worries. i think we're done here.

cheers.




Owen Rubel

unread,
Mar 11, 2015, 11:40:15 PM3/11/15
to api-...@googlegroups.com
No its not that it doesnt provide value. I was just wondering if it should be broken into API versions vs non-api versions or for the api versions require URL because on the server side, it is required for doing the check

mca

unread,
Mar 11, 2015, 11:41:53 PM3/11/15
to api-...@googlegroups.com
i see.

feel free to join us on the ALPS list and we can continue.

cheers.



Reply all
Reply to author
Forward
0 new messages