Skip to main content

Shameless plug - Use the new JobServe Web API to search for jobs your way

As my signature states - I work for JobServe in the UK.  Over the past few months I have been working on a new REST API (using the ASP.Net Web API from pre-beta to RTM) and it is now in official public beta.
Now of course, this isn't just so your good selves can start running your own job searches using whatever web-enabled client takes your fancy, but that is one of the cool benefits that has come out of it - and that's why we're calling it a public beta.
At the time of writing, you can use the API to run almost any job search that you can on the website.  As you would expect, you can get the results in XML or JSON (also GET requests with search parameters in the query-string are supported as well).  Note that JSONP is not currently supported - but it's slated for a future release.

Sounds great, how do I get in?

In order to get cracking with this - you need to request an API token.  This is not an automated process but we should be able to get you set up in a day or two at most.  When filling out this form it's important to be honest about what you intend to do with the API.  That way, we'll know what kind of request patterns to look for and are less likely to revoke access at a later date.

…And then what?

Once you've got your API token - just follow the documentation that I've put together on the JobServe Web API mini-site to get started.  You can contact the support team by email from the site if you have a problem - but please don't contact us looking for code on how to make HTTP requests; that's outside our remit!
If you're environment is .Net, and you don't mind sending/receiving XML, we are making available DataContractSerializer-compatible classes that are generated live from the latest API Types schema.  These are available from the Source Code download page.  These code files (C# and VB.Net available) give you compatible types for all the types used by the API.  Note that these classes aren't, however, natively suitable for JSON - some might work with Json.Net, for example, but they're not intended to.
The most likely usage of this API is to extract the Permalink for a desirable job.  This will take you straight to that job on the JobServe website, from which point you can then apply in the browser as normal.  The sharp-eyed among you will notice in the API types list that clearly we have got objects that can manage the application process outside the browser - but at the moment I'm sorry to say that we have no plans to make that bit public - this is chiefly for the security of our users instead of bloody-mindedness.
So, get yourself signed up for an API token and start writing!  Will you setup an azure service to notify you of jobs?  Perhaps you'll write yourself a personalised search app?  If you want to share any code with us to help others (we might put it on the aforementioned source code page), then please do.

Can I use SSL?

If you're concerned about security - SSL endpoints are available for all operations - just use https://services.jobserve.com instead of http://services.jobserve.com.

Any code samples on the way?

I will try and put together a code example for accessing the service in C# 5 with the 'modern' HttpClient using async/await.  If you do have problems making HTTP requests - then I can also heartily recommend StackOverflow (I am known to hang around there a bit, so I might even see your question) as a great source of help.  Provided, that is, you try your best solve your problem first!

Happy coding!  Oh, and happy job hunting!

Comments

  1. Well done Andras, tempted to put togather a Windows 8 desktop widget now!

    ReplyDelete
    Replies
    1. Thanks!

      Go on - you know you want to... Can't promise you won't have competition though :)

      Delete

Post a Comment

Popular posts from this blog

Asp.Net 2 and 4 default application pool generates CS0016 IIS7.5

Before I start – if you’ve found a bunch of other articles about this around the net, tried the fixes that are mentioned and still not getting any joy – then read on – you might find this solves your problem. Earlier today I discovered that when I run any ASP.Net 2 or 4 application through IIS7.5 using the default application pools (which use ApplicationPoolIdentity) on Windows 2008 R2 x64 I get an error message similar to this: Server Error in '/MvcApplication31' Application. Compilation ErrorDescription: An error occurred during the compilation of a resource required to service this request. Please review the following specific error details and modify your source code appropriately.
Compiler Error Message: CS0016: Could not write to output file 'c:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\mvcapplication31\222b4fe6\4e80a86\App_global.asax.clb4bsnc.dll' -- 'The directory name is invalid. '
Source Error:[No relevant source lines]
Sou…

Serializing to attributes in WCF with DataContractSerializer

It’s a common problem – you want to return an object from a WCF service as XML, but you either want, or need, to deliver some or all of the property values as XML Attributes instead of XML Elements; but you can’t because the DataContractSerializer doesn’t support attributes (you’re most likely to have seen this StackOverflow QA if you’ve done a web search).  Most likely you’ve then migrated all your WCF service code to using the XmlSerializer (with all the XmlElement/XmlAttribute/XmlType attributes et al) – and you’ve cursed loudly.Well, I’m here to rescue you, because it is possible – and the answer to the problem is actually inferred from the MSDN article entitled ‘Types supported by the Data Contract Serializer’.The example I’m going to give is purely for illustration purposes only.  I don’t have a lot of time, so work with me!Create a new Asp.Net WCF service application, you can use Cassini as your web server (probably easier – otherwise you might have to enable Asp.Net compatibil…

Adding ‘Deny’ functionality to AuthorizeAttribute in Asp.Net Web API

For the web service project I’m working on at the moment I need to be able to treat authorization differently based on the hostname of the URL that requests are made through.To state more clearly – these web services will have a ‘sandbox’ mode in addition to the real mode, and the mode a request will operate under is determined as part of the controller-selection phase early in the Web API request lifecycle.  So, say that my web services will be hosted on services.acme.com; the sandbox will simply be sandbox.services.acme.com.Please note – a discussion of how this is implemented is entirely outside the scope of this article; but I’ll just say that I’ve developed an in-house multi-tenancy layer for both MVC 4 and Web API that allows us to define ‘brands’ and, under those, you can then redefine content, controllers, and even the DI container that is used.These services are going to require caller-level authentication for most operations via SCRAM Authentication (RFC 5802), and as such m…