[ckan-discuss] [Fwd: Re: API For Package Name]

[David Read]

John,

This doesn't seem to be RESTful so I wouldn't suggest putting it in
the Model API. Rather, a new 'util' API. James has already documented
this in ckan/doc/api/version2.rst.

e.g. /api/2/util/package/create_slug?title=Package+1+Title+Typed+So+Far

We have one current use case:
* munge a title to a package name
And two similar things done in the data importers, but I see no reason
to have these in the api right now. But I'll mention them in case it
guides the API:
* munge a badly-formed name to a well-formed package name
* munge a word/phrase into a tag name

I'm going to detach all importers from any centralised munger or api,
to ensure they never change.

I'm not convinced adding the word slug in here helps, since only one
purpose of a package name or tag name is to be a slug, although that
is the reason it is constrained.

David

On 23 November 2010 21:34, John Bywater
<john.bywater at appropriatesoftware.net> wrote:
> Hi James,
>
> Just wondering about slugs in the API. Thought I'd copy this to the
> ckan-discuss list, so that others could report whether they prefer:
>
> /api/rest/slug/{string}
>
> or:
>
> /api/rest/package/create_slug?title={string}
>
> as the template locator for slug resources within CKAN's RESTful API.
>
> Best wishes,
>
> John.
>
>
>
>
>
> -------- Original Message --------
> Subject: Re: API For Package Name
> Date: Mon, 15 Nov 2010 22:40:24 +0000
> From: John Bywater <john.bywater at appropriatesoftware.net>
> To: James Gardner <james at 3aims.com>
> References: <1289828618.2508.6.camel at feynman>
>
> Hi James,
>
> Thank you very much for this email....
>
> James Gardner wrote:
>>
>> Hi John,
>>
>> How does it sound putting it here:
>>
>> /api/2/rest/package/create_slug?title=Package+1+Title+Typed+So
>> +Far&callback=callback
>>
>
> How's about we aim for this:
>
> $ curl /api/2/rest/slug/Package+1+Title+Typed+So+Far
> package_1_title_typed_so_far
>
> That is, would it be okay to isolate slugs as a type of model resource?
>
> In the way of a RESTful API, I would prefer not to pass the input string
> as a request parameter, but rather to make it look as if a slug is a
> type of API resource that is available using a resource locator formed
> from the input string.
>
> /api/2/rest/slug/{string}
>
> We can then avoid mixing slugs with packages (and also tags), and then
> also avoid putting the method name "create" in the locator template.
>
> So, as you had it, but without "package", "create", "title", and "?".
>
> If we wanted different flavours (packages names have underscores whilst
> tag names have dashes), we could instead publish:
>
> /api/2/rest/slug/{type}/{string}
>
> or, to make the types clear:
>
> /api/2/rest/slug/underscored/{string}
> /api/2/rest/slug/dashed/{string}
>
> That would fit well with the original design of the CKAN API. ;-)
>
>
>> (This is already implemented now so aside from the URL itself I'd prefer
>> not to discuss other features!!)
>>
>
> I can't think of anything just now... ;-)
>
>
>> I prefer slug but do you prefer name?
>>
>
> I prefer slug: who's to say a slug will be used as a name?
>
> Best wishes,
>
> John.
>
>
>
>> Cheers,
>>
>> James
>>
>>
>>
>
>
> _______________________________________________
> ckan-discuss mailing list
> ckan-discuss at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-discuss
>